ipnat.conf - map and rdr won't work!

alexus alexus at gmail.com
Tue Jul 20 16:02:13 UTC 2010


On Mon, Jul 19, 2010 at 12:38 PM, Erik Norgaard <norgaard at locolomo.org> wrote:
> On 19/07/10 16.46, alexus wrote:
>>>>>
>>>>> Use tcpdump, you should see if your rdr/map rules work as expected.
>>>>> Also,
>>>>> pfctl -ss and similar.
>>>>
>>>> i don't know how to use tcpdump, can you provide exact syntax so i can
>>>> run
>>>> it?
>>>
>>> The man-page is excelent.
>>
>> tried that, unfortunately not really sure what am i doing.. still
>
> Can't help you more, really, you need to investigate where packets are
> dropped, tcpdump is a great tool and the man-page is excelent, can't explain
> it better, if you don't like tcpdump then use any other packet sniffing tool
> at hand, snort for example.

ipmon:

20/07/2010 10:22:00.123106 @2 NAT:RDR 172.16.172.16,22 <- ->
64.52.58.58,22 [69.10.67.106,6346 PR tcp]
20/07/2010 10:26:00.340436 @2 NAT:EXPIRE 172.16.172.16,22 <- ->
64.52.58.58,22 [69.10.67.106,6346 PR tcp] Pkts 11/0 Bytes 640/0

tcpdump:

tcpdump: listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
11:40:07.366519 IP (tos 0x0, ttl 49, id 48580, offset 0, flags [DF],
proto TCP (6), length 64) 69.10.67.106.9408 > 64.52.58.58.22: S, cksum
0xc05d (correct), 208454974:208454974(0) win 65535 <mss
1380,nop,wscale 3,nop,nop,timestamp 91387932 0,sackOK,eol>
11:40:08.346575 IP (tos 0x0, ttl 49, id 19079, offset 0, flags [DF],
proto TCP (6), length 64) 69.10.67.106.9408 > 64.52.58.58.22: S, cksum
0xc054 (correct), 208454974:208454974(0) win 65535 <mss
1380,nop,wscale 3,nop,nop,timestamp 91387941 0,sackOK,eol>
11:40:09.102442 IP (tos 0x0, ttl 49, id 28097, offset 0, flags [DF],
proto TCP (6), length 64) 69.10.67.106.9408 > 64.52.58.58.22: S, cksum
0xc04a (correct), 208454974:208454974(0) win 65535 <mss
1380,nop,wscale 3,nop,nop,timestamp 91387951 0,sackOK,eol>
11:40:10.108089 IP (tos 0x0, ttl 49, id 28130, offset 0, flags [DF],
proto TCP (6), length 64) 69.10.67.106.9408 > 64.52.58.58.22: S, cksum
0xc040 (correct), 208454974:208454974(0) win 65535 <mss
1380,nop,wscale 3,nop,nop,timestamp 91387961 0,sackOK,eol>
11:40:11.104669 IP (tos 0x0, ttl 49, id 27900, offset 0, flags [DF],
proto TCP (6), length 64) 69.10.67.106.9408 > 64.52.58.58.22: S, cksum
0xc036 (correct), 208454974:208454974(0) win 65535 <mss
1380,nop,wscale 3,nop,nop,timestamp 91387971 0,sackOK,eol>
11:40:12.110396 IP (tos 0x0, ttl 49, id 56214, offset 0, flags [DF],
proto TCP (6), length 64) 69.10.67.106.9408 > 64.52.58.58.22: S, cksum
0xc02c (correct), 208454974:208454974(0) win 65535 <mss
1380,nop,wscale 3,nop,nop,timestamp 91387981 0,sackOK,eol>
11:40:14.105642 IP (tos 0x0, ttl 49, id 41429, offset 0, flags [DF],
proto TCP (6), length 64) 69.10.67.106.9408 > 64.52.58.58.22: S, cksum
0xc018 (correct), 208454974:208454974(0) win 65535 <mss
1380,nop,wscale 3,nop,nop,timestamp 91388001 0,sackOK,eol>
11:40:18.114148 IP (tos 0x0, ttl 49, id 30423, offset 0, flags [DF],
proto TCP (6), length 48) 69.10.67.106.9408 > 64.52.58.58.22: S, cksum
0x8b0d (correct), 208454974:208454974(0) win 65535 <mss
1380,sackOK,eol>
11:40:21.899739 arp who-has 64.52.58.36 tell 64.52.58.33
11:40:24.830499 arp who-has 64.52.58.36 tell 64.52.58.33
11:40:26.125568 IP (tos 0x0, ttl 49, id 25515, offset 0, flags [DF],
proto TCP (6), length 48) 69.10.67.106.9408 > 64.52.58.58.22: S, cksum
0x8b0d (correct), 208454974:208454974(0) win 65535 <mss
1380,sackOK,eol>
11:40:42.157443 IP (tos 0x0, ttl 49, id 18773, offset 0, flags [DF],
proto TCP (6), length 48) 69.10.67.106.9408 > 64.52.58.58.22: S, cksum
0x8b0d (correct), 208454974:208454974(0) win 65535 <mss
1380,sackOK,eol>
11:41:14.193555 IP (tos 0x0, ttl 49, id 42007, offset 0, flags [DF],
proto TCP (6), length 48) 69.10.67.106.9408 > 64.52.58.58.22: S, cksum
0x8b0d (correct), 208454974:208454974(0) win 65535 <mss
1380,sackOK,eol>
^C180 packets captured
182 packets received by filter
0 packets dropped by kernel

> Do packets can get dropped because of your firewall default policy? For
> stealth it may be set to simply drop packets which result in a connection
> time-out rather than send a TCP-RST.

su-3.2# grep ^firewall /etc/rc.conf
firewall_enable="YES"
firewall_type="open"
su-3.2# ipfw show
00100   5478    792380 allow ip from any to any via lo0
00200      0         0 deny ip from any to 127.0.0.0/8
00300      0         0 deny ip from 127.0.0.0/8 to any
65000 869903 554820708 allow ip from any to any
65535      0         0 deny ip from any to any
su-3.2# grep ^ip /etc/rc.conf
ipfilter_enable="YES"
ipmon_enable="YES"
ipnat_enable="YES"
ipnat_flags="-d"
su-3.2#

i even did this

su-3.2# /etc/rc.d/ipfw stop
net.inet.ip.fw.enable: 1 -> 0
su-3.2#

> Do packets get dropped because of nat on the way in? or on the way out?

i tried disabling map rule and leave only rdr, that didn't help

> What if you just disable ipnat? What if you flush the firewall rules?
> (disconnect from the Internet first)

if i disable ipnat then map or rdr wont work as they simply disabled

i disabled ipfw, and i dont have any rules inside of ipfilter

> Do you have any logs in the jail that indicate that the first packet is
> actually received? Do your firewall log connections? If not, see how you can
> enable logs on all rules to get more information.

nothing gets to jail there for no logs inside of jail

> Can you connect out from the jail, to external servers? only to the jail
> hosting server? Did the jail's ssh log tell anything?

no i can not connect out from jail, as map doesn't work either
nothing gets to

> You wrote you can connect with ssh from the hosting server to the jail, but
> it took a long time, did you investigate this? Is there some DNS issue that
> times out and causes the connection to fail?
>
> Can you ping your jail? Can you ping out? Default route is configured?

i can ping my jail within host environment
once again nothing within jail works as map (nat) isn't working

default router isn't configured in rc.conf (inside of jail) as per
jail's man page its not needed
it was working fine before without it

> There are tons of tests you can do to figure out what's failing.
>
> BR, Erik
>



-- 
http://alexus.org/


More information about the freebsd-questions mailing list