On 2011-09-09, David Walker <davidianwal...@gmail.com> wrote: > I have some idea IPsec might be useful so I do a search and this comes > up (first cab off the rank) ... > http://www.symantec.com/connect/articles/zero-ipsec-4-minutes > ... it's specifically about OpenBSD and it looks pretty easy. > > So I go to the ipsec(4) man page and see this ... > > If we apply ESP in tunnel mode to the original packet, we would get: > > [IP header] [ESP header] [IP header] [TCP header] [data...] > > Again, everything after the ESP header is cryptographically protected. > Notice the insertion of an IP header between the ESP and TCP header. > This mode of operation allows us to hide who the true source and > destination addresses of a packet are (since the protected and the > unprotected IP headers don't have to be exactly the same). A typical > application of this is in Virtual Private Networks (or VPNs), where two > firewalls use IPsec to secure the traffic of all the hosts behind them. > For example: > > Net A <----> Firewall 1 <--- Internet ---> Firewall 2 <----> Net B > > Firewall 1 and Firewall 2 can protect all communications between Net A > and Net B by using IPsec in tunnel mode, as illustrated above. > > ... which seems to fit the bill if I subsitute "Wireless" for > "Internet" in the diagram. > I should use IKED or ISAKMPD to avoid replay protection. > > Is that sensible? > > Best wishes. > >
iked doesn't handle retransmitting dropped ike packets yet, so it's not a great choice for wireless. isakmpd should be fine though. basic setup: laptop: ike dynamic esp from egress to 0.0.0.0/0 peer 11.22.33.44 # or "from egress to ::/0 ..." for ipv6 # 11.22.33.44 is the router's IP address copy /etc/isakmpd/local.pub from the router to /etc/isakmpd/pubkeys/ipv4/11.22.33.44 router: ike passive esp from any to any copy /etc/isakmpd/local.pub from the laptop to /etc/isakmpd/pubkeys/fqdn/laptop.host.name possible complications:- - if you will be communicating with other machines in the same subnet, they will send return traffic directly rather than via the router, i.e. unencrypted and will not update PF state (so tcp sessions will break after a short time). you can either setup bypass flows in ipsec.conf, use different subnets, maybe other options. - if you run ipsec to a NATting gateway, this will give you some extra fun ;) - ipsec reduces the maximum packet size, you can look at reducing MTU, or 'scrub...max-mss' in PF can help (the latter still gives problems with non-TCP protocols; notably DNS which is slightly affected in rare cases now, and likely to become more of a problem in future).