> Have you tried comparing the packets arriving from the net with those being
> sent to the IPSEC endpoint?
>
> -Tom
The following three monitors are recording the same attempt to connect. First,
on the LAN router, listening to the outside interface:
# tcpdump -vv -i eth0 'udp port 5500 and (((ip[2:2] - ((ip[0]&0xf)<<2)) -
((udp[12]&0xf0)>>2)) != 0)'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144
bytes
08:51:01.009320 IP (tos 0x0, ttl 55, id 4126, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > draco.darkmatter.org.5500: [udp sum ok] UDP, length
708
08:51:02.889997 IP (tos 0x0, ttl 55, id 4127, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > draco.darkmatter.org.5500: [udp sum ok] UDP, length
708
08:51:05.704119 IP (tos 0x0, ttl 55, id 4128, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > draco.darkmatter.org.5500: [udp sum ok] UDP, length
708
08:51:09.663990 IP (tos 0x0, ttl 55, id 4129, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > draco.darkmatter.org.5500: [udp sum ok] UDP, length
708
08:51:15.147943 IP (tos 0x0, ttl 55, id 4130, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > draco.darkmatter.org.5500: [udp sum ok] UDP, length
708
^C
5 packets captured
9 packets received by filter
0 packets dropped by kernel
No idea who 172.58.43.170 is; it changes every attempt and it's not my phone.
Maybe some TMobile interlocutor. So the checksum is Ok, the packet length is
736 bytes, and payload is 708.
Same router, same session, inside interface:
# tcpdump -vv -i eth1 'udp port 500 and (((ip[2:2] - ((ip[0]&0xf)<<2)) -
((udp[12]&0xf0)>>2)) != 0)'
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144
bytes
08:51:01.009360 IP (tos 0x0, ttl 54, id 4126, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > 192.168.111.16.isakmp: [udp sum ok] isakmp 0.0 msgid
21202208 cookie 00000000645eed11->82343c0000000000:
08:51:02.890010 IP (tos 0x0, ttl 54, id 4127, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > 192.168.111.16.isakmp: [udp sum ok] isakmp 0.0 msgid
21202208 cookie 00000000645eed11->82343c0000000000:
08:51:05.704159 IP (tos 0x0, ttl 54, id 4128, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > 192.168.111.16.isakmp: [udp sum ok] isakmp 0.0 msgid
21202208 cookie 00000000645eed11->82343c0000000000:
08:51:09.664003 IP (tos 0x0, ttl 54, id 4129, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > 192.168.111.16.isakmp: [udp sum ok] isakmp 0.0 msgid
21202208 cookie 00000000645eed11->82343c0000000000:
08:51:15.147956 IP (tos 0x0, ttl 54, id 4130, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > 192.168.111.16.isakmp: [udp sum ok] isakmp 0.0 msgid
21202208 cookie 00000000064f3d9f->aeee889100000000:
^C
5 packets captured
6 packets received by filter
0 packets dropped by kernel
Now the whole packet is encapsulated (736 bytes), it seems to be a port 500
packet and the checksum is Ok.
Here's looking at it coming in to the destination IPSec gateway:
# tcpdump -vv -i eth0 'udp port 500 and (((ip[2:2] - ((ip[0]&0xf)<<2)) -
((udp[12]&0xf0)>>2)) != 0)'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144
bytes
08:51:01.009581 IP (tos 0x0, ttl 54, id 4126, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > zeta.darkmatter.org.isakmp: [udp sum ok] isakmp 0.0
msgid 21202208 cookie 00000000645eed11->82343c0000000000:
08:51:02.890141 IP (tos 0x0, ttl 54, id 4127, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > zeta.darkmatter.org.isakmp: [udp sum ok] isakmp 0.0
msgid 21202208 cookie 00000000645eed11->82343c0000000000:
08:51:05.704507 IP (tos 0x0, ttl 54, id 4128, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > zeta.darkmatter.org.isakmp: [udp sum ok] isakmp 0.0
msgid 21202208 cookie 00000000645eed11->82343c0000000000:
08:51:09.664215 IP (tos 0x0, ttl 54, id 4129, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > zeta.darkmatter.org.isakmp: [udp sum ok] isakmp 0.0
msgid 21202208 cookie 00000000645eed11->82343c0000000000:
08:51:15.148127 IP (tos 0x0, ttl 54, id 4130, offset 0, flags [DF], proto UDP
(17), length 736)
172.58.43.170.60925 > zeta.darkmatter.org.isakmp: [udp sum ok] isakmp 0.0
msgid 21202208 cookie 00000000064f3d9f->aeee889100000000:
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel
The packet length is still 736, the port is 500, and checksum is Ok. These all
are on the same attempt to communicate and there doesn't seem to be any
molestation in this chain. But this seems to be before it is decapsulated.
Libreswan is supposed to automatically handle DNAT-T and clearly it does as it
works when not changing ports. And changing ports in this way should not be
visible to it unless there's some damage in the decapsulation process.------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
