[Openswan Users] traffic only being encrypted one way
Bob Benstro
bbenstro at gmail.com
Tue Mar 20 22:15:17 EDT 2007
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.orgadvanced 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
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
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/20070320/fe714429/attachment-0001.html
More information about the Users
mailing list