> On 29 Dec 2014, at 16:20 , Aristedes Maniatis <ari at ish.com.au> wrote: > > I am at wits end trying to get ipsec working correctly on FreeBSD 10.1. I've always used a script or helper (like pfsense) to get it working, and setting it up by hand is much harder than it seems. I've spent two solid days on this and read everything on the internet... > > So, I've got racoon working. The tunnel authenticates and comes up just fine. The racoon logs all look good. The other end (Sophos UTM in my case, which is just linux) also shows everything as up. > > As I understand it, a gif0 tunnel is not needed at all. It should all just work without one, despite the FreeBSD handbook. But I think I'm missing something about how gif0 ties into enc0, firewall rules and routing. So some questions please:If you are trying to setup ipsec tunnel mode between two sites, ignore gif entirely.> 1. Let's say I'm not using gif0. Should I expect some routes to appear in the FreeBSD routing table? Or do I need to put them there myself? If so, what should I be adding? I've seen things like: > > route add $remote_net/24 $remote_internal_address > > But how does the OS know where to send traffic to $remote_internal_address? Is that something racoon takes care of?No, there are no routes involved; your security policy deals with this. setkey -DP is your friend. You can have racoon inject the policy for you if you want, otherwise ipsec.conf is where it goes.> 2. If I am using gif0 do I need to also use gif0 on the other end? This adds another layer of encapsulation which I need to remove at the remote firewall don?t I?Yes.> 3. What does this mean: > > ifconfig gif0 inet 192.168.1.1 192.168.0.1 netmask 0xffffffff > > Is that mask for the remote end or for the local end?Or just to be there.> 4. I'm using pf for a firewall. Other than allowing isakmp, esp and ipencap through in both directions, can I control the traffic inside the tunnel? Do I need to add rules for that traffic or will it always go through?For that you?ll need enc(4) to do it properly. Check the man page for settings. You might want to change them off the defaults. ? Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend."
Ari, Bjoern offers good advise (as usual). This practical example might help, taken from two devices connected to the internet - some numbers and "keys" have obviously been changed to protect the sites concerned. # /etc/ipsec.conf - you should be able to cut/paste and substitute your numbers in this "template" spdadd 101.48.55.78/32[any] 110.92.114.99/32 any -P in ipsec esp/transport/101.48.55.78-110.92.114.99/require; spdadd 110.92.114.99/32[any] 101.48.55.78/32[any] any -P out ipsec esp/transport/110.92.114.99-101.48.55.78/require; spdadd 10.192.0.0/16[any] 10.168.0.0/16[any] any -P in ipsec esp/tunnel/101.48.55.78-110.92.114.99/require; spdadd 10.168.0.0/16[any] 10.192.0.0/16[any] any -P out ipsec esp/tunnel/110.92.114.99-101.48.55.78/require; # These remain the same on the two end-points add 110.92.114.99 101.48.55.78 esp 25131 -E rijndael-cbc "from_here_to_there12345 *"; add 101.48.55.78 110.92.114.99 esp 25136 -E rijndael-cbc "from_there_to_here 12345&"; There is no need to add or change routing nor complicate life with gif. Though you may need to adjust your firewall rules to ipfw add allow esp from 101.48.55.78 to 110.92.114.99 via $internet_interface ipfw add allow esp from 110.92.114.99 to 101.48.55.78 via $internet_interface And it should be noted that when you use enc, that you will need to "ifconfig enc0 up" otherwise its mute. For dynamic addresses, like iphones (ikev1) or windows (ikev2) notebooks, I've found strongswan the tool of choice if you must use the client's native ipsec mechanism. But it is hard to setup, and udp fragmentation may be an issue (as we found because we have large certificates). Merry Christmas, Dewayne.
On 30/12/2014 4:23am, Bjoern A. Zeeb wrote:> >> On 29 Dec 2014, at 16:20 , Aristedes Maniatis <ari at ish.com.au> wrote: >>>> But how does the OS know where to send traffic to $remote_internal_address? Is that something racoon takes care of? > > No, there are no routes involved; your security policy deals with this. setkey -DP is your friend. You can have racoon inject the policy for you if you want, otherwise ipsec.conf is where it goes.# setkey -DP 203.29.62.128/25[any] 10.100.0.0/16[any] any in ipsec ipcomp/tunnel/202.161.111.54-202.127.223.110/use esp/tunnel/202.161.111.54-202.127.223.110/unique#16390 spid=26 seq=3 pid=83060 refcnt=1 203.29.62.128/25[any] 10.101.0.0/16[any] any in ipsec ipcomp/tunnel/202.161.111.54-202.127.223.110/use esp/tunnel/202.161.111.54-202.127.223.110/unique#16392 spid=28 seq=2 pid=83060 refcnt=1 10.100.0.0/16[any] 203.29.62.128/25[any] any out ipsec ipcomp/tunnel/202.127.223.110-202.161.111.54/use esp/tunnel/202.127.223.110-202.161.111.54/unique#16389 spid=25 seq=1 pid=83060 refcnt=1 10.101.0.0/16[any] 203.29.62.128/25[any] any out ipsec ipcomp/tunnel/202.127.223.110-202.161.111.54/use esp/tunnel/202.127.223.110-202.161.111.54/unique#16391 spid=27 seq=0 pid=83060 refcnt=1 Does that look right for a setup with two tunnels (two networks at one end) and compression enabled? If racoon is showing the tunnels as UP: 2014-12-30 12:01:48: INFO: initiate new phase 2 negotiation: 202.127.223.110[500]<=>202.161.111.54[500] 2014-12-30 12:01:48: INFO: IPsec-SA established: ESP/Tunnel 202.127.223.110[500]->202.161.111.54[500] spi=26332262(0x191cc66) 2014-12-30 12:01:48: INFO: IPsec-SA established: IPCOMP/Tunnel 202.127.223.110[500]->202.161.111.54[500] spi=1336(0x538) 2014-12-30 12:01:48: INFO: IPsec-SA established: ESP/Tunnel 202.127.223.110[500]->202.161.111.54[500] spi=91459320(0x5738ef8) 2014-12-30 12:01:48: INFO: IPsec-SA established: IPCOMP/Tunnel 202.127.223.110[500]->202.161.111.54[500] spi=32553(0x7f29) Am I right in saying that I would not get this far if setkey wasn't already correct? But still I cannot ping the remote internal IP (203.29.62.129). I also notice that other addresses in the remote network except for the remote firewall itself are not sent through the tunnel. I guess I'll need to add a route for those after all. Are you able to suggest my next step in diagnosis. Everything seems to be working... other than traffic going into the tunnel and coming out the other side :-)>> 2. If I am using gif0 do I need to also use gif0 on the other end? This adds another layer of encapsulation which I need to remove at the remote firewall don?t I? > > Yes.Then I think the FreeBSD handbook really needs adjustment because it explains that gif is a definite requirement.>> 3. What does this mean: >> >> ifconfig gif0 inet 192.168.1.1 192.168.0.1 netmask 0xffffffff >> >> Is that mask for the remote end or for the local end? > > Or just to be there. > > >> 4. I'm using pf for a firewall. Other than allowing isakmp, esp and ipencap through in both directions, can I control the traffic inside the tunnel? Do I need to add rules for that traffic or will it always go through? > > For that you?ll need enc(4) to do it properly. Check the man page for settings. You might want to change them off the defaults.Until I recompile my kernel for ENC, can I assume that packet filter rules aren't going to be my problem here (other than the obvious rules which allow IPSec to be established, which is working). Thanks again Ari -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
> On 30 Dec 2014, at 05:22 , Aristedes Maniatis <ari at ish.com.au> wrote: > > On 30/12/2014 4:23am, Bjoern A. Zeeb wrote: >> >>> On 29 Dec 2014, at 16:20 , Aristedes Maniatis <ari at ish.com.au> wrote: >>> > > >>> But how does the OS know where to send traffic to $remote_internal_address? Is that something racoon takes care of? >> >> No, there are no routes involved; your security policy deals with this. setkey -DP is your friend. You can have racoon inject the policy for you if you want, otherwise ipsec.conf is where it goes. >?> Am I right in saying that I would not get this far if setkey wasn't already correct? > > > But still I cannot ping the remote internal IP (203.29.62.129). I also notice that other addresses in the remote network except for the remote firewall itself are not sent through the tunnel. I guess I'll need to add a route for those after all. > > Are you able to suggest my next step in diagnosis. Everything seems to be working... other than traffic going into the tunnel and coming out the other side :-)Hint: not sure if you are testing from the gateway itself; if you do you might have to use a specific source address (internal) with ping/telnet/etc. Otherwise, read man setkey on the difference of ?use? vs. ?require? vs. ?unique? for the level in the policy part. ? Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend."
Harry Schmalzbauer
2015-Jan-05 09:14 UTC
PMTU (must fragment) with ipsec [Was: Re: ipsec routing issue]
Bez?glich Dewayne Geraghty's Nachricht vom 30.12.2014 01:09 (localtime):> Ari, > > Bjoern offers good advise (as usual). This practical example mightHello, I'm quiet familar with ipsec(4), enc(1) and companions, but I haven't found a way to make routers return ICMP "must fragment" with gif-less tunnels. My last attempt was adding disc(4), assign it a MTU of 1420 and add a static route which points to disc. That works for 'route get remotelan' on the router itself, it's reporting correctly the mtu of 1420, but nevertheless, the router never returns "must fragment" (which I'd need because FreeBSD has PMTU on and we use jumbo frames). Apperently fragementation is handled before packets arrive at the outgoing interface. Of course, kernel policy "steals" the packet before ot reaches "outgoing" state. Do I miss any trick? Thanks, -Harry