[Openswan Users] traffic only being encrypted one way
Bob Benstro
bbenstro at gmail.com
Wed Mar 21 23:36:51 EDT 2007
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/20070321/5e1c69ca/attachment-0001.html
More information about the Users
mailing list