[Openswan Users] Simple IPSec tunnel. OpenSwan, NETKEY,
Shorewall. Connection up, but won't route.
Andy
fs at globalnetit.com
Mon Jun 19 22:33:09 CEST 2006
On Tue, 2006-06-20 at 08:22 +0800, Jim Barber wrote:
> Okay I still haven't got everything solved...
> Now that my home network is working I'm now connecting my Work network to another one of our offices.
>
> I'm having trouble routing a little further into a remote network.
> Let me draw a quick diagram expanding on the network at work:
>
> (local) 10.10.0.1 ---> IPSec tunnel --> (remote) 10.100.2.2 ---> 10.100.2.1 (gateway) 192.168.254.253 --> 192.168.254.0/24
>
> I'm not mentioning the public IP of the local and remote hosts since they don't matter and the link is up successfully.
> The IPSec connection is to a dedicated network appliance (Fortigate) with an IP address of 10.100.2.2 on its internal interface.
> The gateway further on is a Linux box that has multiple network interfaces and is attached to various networks.
> I've shown its 10.100.2.1 interface that is connected to the Fortigate box, and its 192.168.254.253 interface that is connected to the LAN over there.
> On this gateway, I've added a route that allows it to route 10.10.0.0/24 network back to the Fortigate box.
>
> Now, from the 10.10.0.1 host I can ping both 10.100.2.2 on the Fortigate box and 10.100.2.1 on the remote gateway.
> I've tried adding a route to the 10.10.0.1 for the 192.168.0.0/24 network to go via 10.100.2.2
> But if I ping 192.168.254.253, then I don't get a response.
>
> I've added the route using the old syntax of: route add -net 192.168.0.0 netmask 255.255.0.0 gw 10.100.2.2
>
You can't do that. Generally, don't try to mess with the routing
yourself. If the tunnel policies are right, routing will just work.
Just add additional conn sections to define appropriate policies.
Consider the source and destination addresses of the packets you need to
send & receive, be sure you have an active tunnel whose left- and right-
subnets match those packets.
In this case, it looks like you need a second conn identical to your
existing one except it'll have rightsubnet=192.168.254.0/24
Of course the peer security gateway will need the additional conn
definition as well. If you do it right, you'll find you have 2 IPsec
SAs, but just 1 ISAKMP SA.
> I've checked firewall rules on all hosts and I'm not seeing the traffic being blocked anywhere...
> I've turned on all logging on the Fortigate box and while I can see the traffic when I ping 10.100.2.1, I don't see any attempt to reach 192.168.254.253
> This suggests to me that the route I've added is not working.
>
> Is there something special I need to do to be able to create a route to the IPSec tunnel on the Linux box?
>
> I also tried the 'ip route' command to add the route.
> Here are my results:
>
> 1. # ip route add 192.168.0.0/24 dev isp scope link via 10.100.2.2
> RTNETLINK answers: Network is unreachable
>
> 2. # ip route add 192.168.0.0/24 scope link via 10.100.2.2
> RTNETLINK answers: Network is unreachable
>
> 3. # ip route add 192.168.0.0/24 dev isp via 10.100.2.2
>
> 4. # ip route add 192.168.0.0/24 via 10.100.2.2
>
> For the old 'route add' command and options 1 and 2 above, a traceroute goes nowhere...
> But for options 3. and 4. the traceroute tries to go out over the Internet instead of into the IPSec tunnel...
>
> How about for Openswan, is there a parameter I need to set to tell the tunnel what other address ranges are on the other side of it?
>
> Any ideas?
>
> ----------
> Jim Barber
> DDI Health
>
>
> Jim Barber wrote:
> >>> 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
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
--
Andy <fs at globalnetit.com>
More information about the Users
mailing list