[Openswan Users] Simple IPSec tunnel. OpenSwan, NETKEY, Shorewall. Connection up, but won't route.

[Jim Barber]

>>The behaviour of the connection has changed, but there is progress as I think traffic is getting through now...
>>Pings and traceroutes appear to go nowhere at all.
>>Upon further investigation I notice that this is because the firewall is now getting in the way.
>>However it's wierd, since the traffic I see in the reject log has the public addresses in the source and destination fields.
>>For example, if I run a 'ping 10.10.0.1' from my home machine I get 100% packet loss.
>>But the firewall logs on my work machine shows the following:
>>
>>     Shorewall:all2all:REJECT: IN=isp OUT= MAC=00:14:6c:72:fd:41:00:12:01:3e:28:d0:08:00  SRC=xxx.xxx.xxx.xxx DST=yyy.yyy.yyy.yyy LEN=104 TOS=08 PREC=0x00 TTL=58 ID=2561 DF PROTO=4
>>
>>Protocol 4 according to my /etc/protocols file is as follows:
>>     ipencap 4       IP-ENCAP        # IP encapsulated in IP (officially ``IP'')
>>
>>Is this how the NETKEY IPSec tunnels appear?
>>ie, rather than traffic looking like it came from 10.1.1.1 to 10.10.0.1 it comes from xxx.xxx.xxx.xxx to yyy.yyy.yyy.yyy as ipencap packets?
>>
>>I'm guessing I may just need to open up a firewall rule to allow protocol 4 to pass between the public addresses of the 2 end points.
>>I had already opened up isakmp(500), 4500, and protocol esp, and protocol ah.
>>Does that sound right to you guys?
> 
> Probably right. Did you try that yet?
> Maybe first try with the firewall disabled completely. I'm not familiar
> with shorewall, so I can't comment on your settings.

I added the rule to allow the protocol 4 in, but it still didn't allow it (blocked exactly the same).
I'm not sure why, it has me scratching my head...
Even though you don't use shorewall, I'll show the entry I added to work's /etc/shorewall/rules file just in case someone else sees the problem.

	#ACTION                 SOURCE          DESTINATION             PROTO
	ACCEPT                  net             fw                      ipencap

The appropriate lines in the output from 'iptables -L -v' generated from this rule is as follows:

	Chain INPUT (policy DROP 0 packets, 0 bytes)
	 pkts bytes target     prot opt in     out     source               destination
	16540   20M isp_in     all  --  isp    any     anywhere             anywhere

	Chain isp_in (1 references)
	 pkts bytes target     prot opt in     out     source               destination
	16536   20M net2fw     all  --  any    any     anywhere             anywhere            policy match dir in pol none

	Chain net2fw (1 references)
	 pkts bytes target     prot     opt in     out     source     destination
	    0     0 ACCEPT     ipencap  --  any    any     anywhere   anywhere

Where 'isp' is the name (renamed from eth1) of the network interface connected to the Internet to the work machine.

Actually, I've just solved it...
Typing this up made me realise, that I've put the ipencap rule on the wrong part.
The rule should be stated at work as:

	#ACTION                 SOURCE          DESTINATION             PROTO
	ACCEPT                  gecko           fw                      ipencap

And at home as:

	#ACTION                 SOURCE          DESTINATION             PROTO
	ACCEPT                  ddi             fw                      ipencap

This is for the ipsec policy matches I had defined earlier...
That allowed the pings to pass between the tunnel end points.

Another thing I notice is that the private addresses are what are used when a forward chain is hit.
ie, if I ping from my home gateway into the 10.10.0.0/24 network I see the packets getting dropped with the private address space in the source and destination fields.
That's fine, I just need to open up the protocols I want to the particular machines I want and I should be away.

I think the Openswan documentation may be a little out of date when it comes to the newest features of the NETKEY implementation and how it behaves.
Without this mailing list we'd be stuck. :)

> I also encountered this IPIP (protocol 4) thing just recently, after I
> upgraded one of my VPN servers to 2.6.16.x. Probably a side effect of
> the ipsec changes in 2.6.16 for iptables/ipsec policy rules. I haven't
> had time to investigate it yet. Adding a permit rule for protocol 4
> worked around it for me.
> 
> BTW - you only need udp/500 and esp for these conns - not udp/4500 or
> ah. But you may need them later, I guess...

Yeah, I'm aware that the 4500 port only comes into play for NAT-T connections...
I had it opened since just under a year ago I had this server successfully act as an IPSec/L2TP server for Windows VPN clients.
At the time it was connected to the net differently and had it's interface NATed...
But that stopped working somewhere along the line, I couldn't work out why, I didn't have the time to look into it since it wasn't important.
I'm sure now that I understand how the traffic is flowing I could go back and address that as well.

This however was pretty important for me to work out since in the next few days I'm required to tie a couple of networks together for work purposes, and so I figured I'd trial it with my home machine first to get an understanding of how to do it.

Thanks for your help.
Hopefully this will be of use to someone else.

----------
Jim Barber
DDI Health