"Jean Caron" <caronj@xxxxxxxxx> writes: > Ola, Your problem is directly related to NAT. You can not use NAT. ESP > will not establish any security association if the source or > destination address have been modified, which is exactly what NAT does > to your packets. In order for this to work, you need to encapsulate > your ESP (IPsec) traffic within either UDP or TCP. NAT-Traversal does > this. Different vendors implement this using different ports.protocol, > but essentially they are encapsulating the orignal packets, hiding the > info from NAT. The iptable rules above are exactly what you'd need if > the tunnel was terminating ON the firewall. But to terminate it PAST > the firewall, unless you use public addresses everywhere (no NAT), you > will need to encapsulate, and define approriate (additional) rules on > your firewall fot the NAT-T port used. Hope this helps, > Jean Right. I went back to Ethereal to have another look. It seems to report the inner most protocol it can decode (in the view I posted initially). Looking at the packet in detail gives this: Frame 275 (160 bytes on wire, 160 bytes captured) Linux cooked capture Internet Protocol, Src Addr: 102.168.3.249 (192.168.3.249). Dst Addr: 1.2.3.4 (1.2.3.4) user Datagram Protocol, Src Port: 4500 (4500), Dst Port: 4500 (4500) UDP Encapsulation of IPsec Packets Encapsulating Security Payload So, you're right it is encapsulated in some form. Also, colleagues using e.g. D-Link routers have no problems connecting. So the traffic should NAT OK. I will now try the patch-o-matic dropped-table to try to understand we the packets get dropped instead of NATed (as suggested by Samuel Jean). -- /Ola Nilsson
