[Openswan Users] traffic only being encrypted one way
Bob Benstro
bbenstro at gmail.com
Sun Mar 25 13:49:05 EDT 2007
Well, today I had some time. I installed a virgin kernel, and made sure the
system came up with the internal 192.168.0.0/24 network only. I then ssh'd
in via another box, added the DSL modem only, and started things from there.
No fancy routes, no patched kernel, nothing in iptables, although I did turn
on ipforwarding of course, in /proc.
I still am unable to ping the remote/road warrior box, or connect to it in
any way, while it has full access to the local box / net.
Something very odd is going on here, and this can definitely be targetted at
my ipsec.conf or openswan itself. Since Paul has said he did not see
anything odd in my ipsec.conf, I would imagine that I might be hitting a bug
in openswan?
Does anyone have any ideas, as to what could be causing this silliness?
Thanks
On 3/21/07, Bob Benstro <bbenstro at gmail.com> wrote:
>
>
> Could someone verify my config, at least?
>
> Thanks
>
>
> On 3/20/07, Bob Benstro <bbenstro at gmail.com> wrote:
> >
> >
> > Paul / Harald,
> >
> > Finally managed to get a hub hooked up today. The packets I'm now
> > seeing are PPPOE encapsulated, so, I know I'm looking at things via tcpdump
> > after it's left for the modem.. and openswan should have done its work.
> >
> > I'm seeing packets routed for 192.168.15.90 over the net, as I described
> > before. :/ Something is definitely wonky here. Just to be sure, I removed
> > all iptables rules, removed all routes, and started with a fresh routing
> > table. I brought up one PPPOE interface / modem, restarted IPSEC, and went
> > from there.
> >
> > Packets left via the correct route, but were still PPPOE encapasuated
> > but not IPSEC encrypted.
> >
> > On this box I'm using the routing patches described on the
> > http://lartc.org advanced routing howto (near the bottom of this page):
> >
> > http://lartc.org/howto/lartc.rpdb.multiple-links.html#AEN298
> >
> > The link points to here:
> >
> > http://www.ssi.bg/~ja/#routes <http://www.ssi.bg/%7Eja/#routes>
> >
> > I'm using kernel 2.6.17.7.
> >
> > I have 4 cable modems and 2 DSL modems hooked up in this configuration..
> > however, so far Openswan has worked flawlessly using l2tpd. It is only when
> > I have gone into a linux to linux setup that problems exist. For example, I
> > have one l2tp connected host up right now, and I can ping it without issue.
> >
> > Suggesting that routing might be mucking with things, or NAT rules makes
> > sense.. as all of my l2tpd routed openswan connections use non-private IP
> > space in the routing table, and all of my openswan to openswan connections
> > use private subnet routes/addresses. Still, I flushed all routes via ip
> > route flush, and iptables via -F, and confirmed they had vanished. This
> > should not be the cause, then.
> >
> > Roadwarrior side:
> >
> > config setup
> > nat_traversal=yes
> > nhelpers=0
> >
> > include /etc/ipsec.d/examples/no_oe.conf
> >
> > conn rw
> > dpdaction=restart
> > dpdtimeout=120
> > authby=rsasig
> > pfs=no
> > keyingtries=3
> > left=%defaultroute
> > leftcert=/etc/ipsec.d/rw.pem
> > leftrsasigkey=%cert
> > right= 1.1.1.1
> > rightcert=base.pem
> > rightsubnet= 192.168.0.0/24
> > auto=start
> >
> > The 'base' has a more complex configuration, naturally:
> >
> > config setup
> > nat_traversal=yes
> > virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.2.0/24<http://10.0.0.0/8,%25v4:172.16.0.0/12,%25v4:192.168.0.0/16,%25v4:%21192.168.2.0/24>
> >
> > conn %default
> > compress=yes
> > authby=rsasig
> > pfs=no
> > leftcert=base.pem
> > right=%any
> > rightca=%same
> > rightrsasigkey=%cert
> > rightsubnet=vhost:%no,%priv
> > auto=add
> > keyingtries=3
> >
> > #Disable Opportunistic Encryption
> > include /etc/ipsec.d/examples/no_oe.conf
> >
> > conn internal
> > left=192.168.0.1
> > leftprotoport=17/1701
> > rightprotoport=17/1701
> >
> > conn cable1
> > left=3.3.3.3
> > leftnexthop= 3.3.3.4
> > leftprotoport=17/1701
> > rightprotoport=17/1701
> >
> > conn pppoe1
> > left= 1.1.1.1
> > leftnexthop= 1.1.1.2
> > leftprotoport=17/1701
> > rightprotoport=17/1701
> >
> > conn pppoe2
> > left=2.2.2.2
> > leftnexthop=2.2.2.3
> > leftprotoport=17/1701
> > rightprotoport=17/1701
> >
> > conn internal10
> > left=10.10.10.1
> > leftprotoport=17/1701
> > rightprotoport=17/1701
> >
> > conn rw
> > auto=add
> > left=1.1.1.1
> > leftnexthop= 1.1.1.2
> > leftsubnet=192.168.0.0/24
> > rightnexthop=%defaultroute
> > rightcert=rw.pem
> >
> >
> > I'm not sure where else to go from here. Keep in mind, as review, the
> > connection does come up and works perfectly from the road warrior side. I
> > can connect to sendmail, imap, you name it .. but I am unable to get any
> > packets initiated from the base to the road warrior...
> >
> > Thanks (I hope!! ;)
> >
> >
> >
> > On 3/16/07, Bob Benstro < bbenstro at gmail.com> wrote:
> > >
> > >
> > >
> > > On 3/16/07, Paul Wouters < paul at xelerance.com> wrote:
> > > >
> > > > On Fri, 16 Mar 2007, Bob Benstro wrote:
> > > >
> > > > > > Most often this is due to the vpn server not being the default
> > > > gateway, and
> > > > > > the local subnet sending the traffic for the vpn to the default
> > > > gateway,
> > > > > > instead of the vpn server.
> > > > > >
> > > > > >
> > > > > I'm not sure what you mean. It seems weird that you've removed
> > > > from my
> > > > > quoted material above, the text that provides information showing
> > > > this isn't
> > > > > the case.
> > > >
> > > > I did not see that information in your email.
> > > >
> > > > > Anyhow, as I mentioned, the traffic is indeed leaving the
> > > > correctly routed
> > > > > interface as it should be. The only problem is that the traffic
> > > > leaving
> > > > > that interface is not encrypted. It is, however, leaving the
> > > > interface it
> > > > > should be leaving, in order to reach the remote box. My local
> > > > subnet and
> > > > > its default route is not in question, as I am performing all tests
> > > > on the
> > > > > VPN box itself, so no need to worry there.
> > > >
> > > > Okay. Are you sure the traffic leaves unencrypted? If you use KLIPS,
> > > > that is
> > > > indeed easy to see, just compare outgoing physical interface with
> > > > ipsecX
> > > > interface. With NETKEY, you don't get to see the encrypted packets
> > > > before they
> > > > leave your box, they are encrypted AFTER tcpdump can see them, so
> > > > this cannot
> > > > be proven using the sending box.
> > >
> > >
> > >
> > > Hmm. Well, I'm using NETKEY, I haven't patched my kernel or anything
> > > of the sort. There is no ipsecX device for me.
> > >
> > > However, on the remote box, I can definitely see encrypted packets,
> > > although I suppose these could merely be packets returning when I am pinging
> > > or otherwise. This lead me to believe that I should be able to see
> > > encrypted packets, but fair enough.
> > >
> > >
> > > Since if they were cleartext, they would go
> > > > to some unknown private space and get dropped, you cannot see it on
> > > > the receiving
> > > > end either. But you might see encrypted packets arriving on the
> > > > receiving end,
> > > > which are never successfully decrypted for some reason (NAT, ipsec
> > > > passthrough
> > > > corruption, etc).
> > >
> > >
> > >
> > > No, unfortunately there is absolutely no incoming traffic on the
> > > remote box that I can see, when pinging/etc from the local to remote box,
> > > encrypted or otherwise. :/
> > >
> > >
> > > Then there is also the possibility you are in fact sending out
> > > > encrypted ESP
> > > > packets (which you can't see when using NETKEY), but some filter
> > > > somewhere filters
> > > > the ESP packets and they never arrive at the destination. Again, you
> > > > would
> > > > not be able to easilly distinguish this from the case they are never
> > > > encrypted,
> > > > send to a bogus router and dropped.
> > >
> > >
> > >
> > > This could indeed be the case... but I suppose I would need to hookup
> > > a hub and another box to watch for said case? Can you think of an easier
> > > way?
> > >
> > > Right now, if I tracedump to the remote box outside of the openswan
> > > setup (direct external IP to external IP), I get a successful traceroute of
> > > about 9 hops, ending at the remote box. If I tracedump using the extruded
> > > IP from the remote box, it drops on the floor after 4 hops, which could
> > > support your theory of a router dropping them along the way. Blech. :/
> > >
> > >
> > >
> > > This is why I asked for more information. Knowing whether you use
> > > > KLIPS or NETKEY
> > > > on the sending end would help reduce the possible scenarios.
> > > >
> > > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20070325/de5bdc20/attachment.html
More information about the Users
mailing list