From: jtub...@gmail.com [mailto:jtub...@gmail.com] On Behalf Of Jason Tubnor Sent: Tuesday, November 03, 2015 1:44 AM To: igyht Cc: OPENBSD forum Subject: Re: iked & nat-t problem (no keep alive)
On 19 October 2015 at 21:49, igyht <igor.k...@zg.htnet.hr> wrote: I am testing iked on OpenBSD phobos 5.7 GENERIC#738 i386, I think there is keep-alive problem when use with NAT-T, detailed configurations are: http://daemonforums.org/showthread.php?t=9446 I think, iked & nat-t need some kind of "keep alive", but I can't find it in iked.conf configuration. Any idea? Keep alive is not really the best way to do it and from memory, the RFC states it shouldn't be done (though I think the NAT-T RFC stated it could, but might be getting a whole lot of them mixed up). To keep your link alive, it is easier to be done at the firewall level. Depending on your firewall or NAT device you can configure to use what is known as 'static-port'. Good firewalls like PF use upper port ransomisation for NAT connections, as you have found out, the state expires and when you try to send data again, the firewall sets up a new UDP 4500 link but return responses will be back to the original client port, not the new one that is setup - thus dropped packets and you need to re-initialise the link. The RFC states that the client (active) is not allowed to send the server (passive) the new return port to prevent DDoS occurring on the server. The best way I have found to solve this problem is configuring a match rule specifically for NAT outbound to remote [any] 4500 static-port (see man 5 pf.conf), leaving good port ransomisation in place for all other traffic. Seems the network admins leave static-port matching on on Cisco routers so I haven't had any issues when connecting through these. Cheers, Jason. -- "If my calculations are correct, when this baby hits 88MPH, you're gonna to see some serious shit" - Emmett "Doc" Brown Yes, I understand your idea, but âroad warrirorâ ie âactive ike deviceâ is not behind pf. Roadwarriror is not behind MY firewall at all, It is somewhere out there, behind some other company/hotel/ISP firewall. Igor