[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problem with PF/GM (little off topic, and LONG, because of logs..)



Hello,

I known that the best ML to ask is pf_(_at_)_benzedrine_(_dot_)_cx, but... i don't receive any anwsers. Are they on vacation ? :-)

The problem which I have is very special, and I can assure you I have tried all of methods, without results. I hope someone in this ML can find the problem...

First of all, I use OpenBSD 3.3, Stable branch, and this is a gateway to share the net from my local network. (NAT). Of course, this box containt 2 interfaces, ne0 for external, and rl0 for internal.

Rules in /etc/pf.conf:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ sudo cat /etc/pf.conf

# Macros: define common values, so they can be referenced and changed easily.
ext_if="ne0"
int_if_1="rl0"
internal_1="192.168.1.0/24"
rick="192.168.1.2"


set loginterface ne0

nat on $ext_if from $internal_1 to any -> ($ext_if)

# dcc
rdr on $ext_if proto tcp from any to ($ext_if) port 2000:2020 -> $rick port 2000:*



# netmeeting/gnomemeeting
rdr on $ext_if proto tcp from any to ($ext_if) port 1720 -> $rick port 1720
rdr on $ext_if proto tcp from any to ($ext_if) port 30000:30010 -> $rick port 30000:*
rdr on $ext_if proto udp from any to ($ext_if) port 5000:5003 -> $rick port 5000:*


# rdr outgoing FTP requests to the ftp-proxy
rdr on $int_if_1 proto tcp from any to any port ftp -> 127.0.0.1 port 8021

# to insure they will pass
pass in on $ext_if inet proto tcp from any to ($ext_if) port 1720 keep state
pass in on $ext_if inet proto udp from any to ($ext_if) port 4999 >< 5011 keep state
pass in on $ext_if inet proto tcp from any to ($ext_if) port 29999 >< 30011 keep state
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Rules loaded:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ sudo pfctl -s nat
nat on ne0 inet from 192.168.1.0/24 to any -> (ne0)
rdr on ne0 inet proto tcp from any to (ne0) port 2000:2020 -> 192.168.1.2 port 2000:2020
rdr on ne0 inet proto tcp from any to (ne0) port = 1720 -> 192.168.1.2 port 1720
rdr on ne0 inet proto tcp from any to (ne0) port 30000:30010 -> 192.168.1.2 port 30000:30010
rdr on ne0 inet proto udp from any to (ne0) port 5000:5003 -> 192.168.1.2 port 5000:5003
rdr on rl0 inet proto tcp from any to any port = ftp -> 127.0.0.1 port 8021


$ sudo pfctl -s rules
pass in on ne0 inet proto tcp from any to (ne0) port = 1720 keep state
pass in on ne0 inet proto udp from any to (ne0) port 4999 >< 5011 keep state
pass in on ne0 inet proto tcp from any to (ne0) port 29999 >< 30011 keep state
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


As told on FAQ by gnomemeeting: http://www.gnomemeeting.org/faq/x269.html#AEN308

Notice: GnomeMeeting have a feature which I can put an external interface in configuration, so it can be possible to use it without proxy/wathever in gateway.

The problem is: the packets are not redirected. A least some of them. Wanna proof? There are snippet of tcpdump on a external inteface, internal interface from openbsd, and finally, from my machine on a local network. They are not perfectly synchronized, but it's sufficient to show as examples. Anyway, you can have tcpdump's binary files[1].

Sniffing on ne0 (external):

17:20:01.115128 remote.49606 > gateway.5002:  udp 489 [tos 0x60]
17:20:01.150493 gateway.1234 > remote.49606:  udp 284 (DF) [tos 0x10]
17:20:01.155267 remote.49606 > gateway.5002:  udp 321 [tos 0x60]
17:20:01.194859 remote.49606 > gateway.5002:  udp 357 [tos 0x60]
17:20:01.200317 gateway.1234 > remote.49606:  udp 1017 (DF) [tos 0x10]
17:20:01.370580 gateway.1234 > remote.49606:  udp 997 (DF) [tos 0x10]
17:20:01.431342 remote.49606 > gateway.5002:  udp 493 [tos 0x60]
17:20:01.467534 remote.49606 > gateway.5002:  udp 280 [tos 0x60]
17:20:01.530761 gateway.1234 > remote.49606:  udp 1029 (DF) [tos 0x10]
17:20:01.644514 remote.49606 > gateway.5002:  udp 411 [tos 0x60]
17:20:01.704229 remote.49606 > gateway.5002:  udp 426 [tos 0x60]
17:20:01.720587 gateway.1234 > remote.49606:  udp 279 (DF) [tos 0x10]
17:20:01.762774 remote.49606 > gateway.5002:  udp 500 [tos 0x60]
17:20:01.770372 gateway.1234 > remote.49606:  udp 1030 (DF) [tos 0x10]
17:20:01.939777 remote.49606 > gateway.5002:  udp 427 [tos 0x60]
17:20:01.940283 gateway.1234 > remote.49606:  udp 987 (DF) [tos 0x10]
17:20:01.995271 remote.49606 > gateway.5002:  udp 480 [tos 0x60]

Snippet from internal interface:
17:20:01.940063 local.5002 > remote.49606:  udp 987 (DF) [tos 0x10]
17:20:02.100378 local.5002 > remote.49606:  udp 1032 (DF) [tos 0x10]
17:20:02.270023 local.5002 > remote.49606:  udp 286 (DF) [tos 0x10]
17:20:02.320526 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:02.347419 local.5002 > remote.49606:  udp 292 (DF) [tos 0x10]
17:20:02.420099 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:02.477382 local.5002 > remote.49606:  udp 169 (DF) [tos 0x10]
17:20:02.548380 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:02.623911 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:02.678261 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:02.749056 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:02.817317 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:02.879111 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:02.926525 remote.49607 > local.5003:  udp 88
17:20:02.947969 local.5002 > remote.49606:  udp 421 (DF) [tos 0x10]
17:20:03.017024 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:03.087318 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:03.153555 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:03.218062 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:03.288225 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:03.347915 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:03.417726 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]
17:20:03.486894 local.5002 > remote.49606:  udp 30 (DF) [tos 0x10]

Snippet from my machine:
17:21:05.245149 local.5002 > remote.49606: udp 30 (DF) [tos 0x10]
17:21:05.271979 local.5002 > remote.49606: udp 292 (DF) [tos 0x10]
17:21:05.344706 local.5002 > remote.49606: udp 30 (DF) [tos 0x10]
17:21:05.401960 local.5002 > remote.49606: udp 169 (DF) [tos 0x10]
17:21:05.472990 local.5002 > remote.49606: udp 30 (DF) [tos 0x10]
17:21:05.548509 local.5002 > remote.49606: udp 30 (DF) [tos 0x10]
17:21:05.602861 local.5002 > remote.49606: udp 30 (DF) [tos 0x10]
17:21:05.673645 local.5002 > remote.49606: udp 30 (DF) [tos 0x10]
17:21:05.741897 local.5002 > remote.49606: udp 30 (DF) [tos 0x10]
17:21:05.803686 local.5002 > remote.49606: udp 30 (DF) [tos 0x10]
17:21:05.851246 remote.49607 > local.5003: udp 88
17:21:05.872426 local.5002 > remote.49606: udp 421 (DF) [tos 0x10]
17:21:05.941573 local.5002 > remote.49606: udp 30 (DF) [tos 0x10]
17:21:06.011866 local.5002 > remote.49606: udp 30 (DF) [tos 0x10]
17:21:06.078083 local.5002 > remote.49606: udp 30 (DF) [tos 0x10]
17:21:06.142597 local.5002 > remote.49606: udp 30 (DF) [tos 0x10]

As you can notice, only the port 5003 is forwarded, but not 5002. The problem is me or OpenBSD cannot handle port 5002 in both direction? Am I missing something?

I have wrote to the author of gnomemeeting, and he told me that the others users don't have this problem... He don't told me if they are using OpenBSD as gateway, but I guess that the majority use Linux as gateway.

Finally, as you can see below, I have forwarded port 2000 to 2020 too, for DCC chat/send in IRC clients, and it's work PERFECTLY !

There are tcpdump files for analyzis if you want:

http://www.toodark.org/external
http://www.toodark.org/internal
http://www.toodark.org/machine

Two first is "sniffed" on OpenBSD machine, on a external and internal interface, and the last is "sniffed" on my machine in local network.

Thank you very much for you help.

J.

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail




Visit your host, monkey.org