<br>Well, today I had some time. I installed a virgin kernel, and made sure the system came up with the internal <a href="http://192.168.0.0/24">192.168.0.0/24</a> network only. I then ssh'd in via another box, added the DSL modem only, and started things from there.
<br><br>No fancy routes, no patched kernel, nothing in iptables, although I did turn on ipforwarding of course, in /proc.<br><br>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.
<br><br>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?
<br><br>Does anyone have any ideas, as to what could be causing this silliness?<br><br>Thanks<br><br><br><br><div><span class="gmail_quote">On 3/21/07, <b class="gmail_sendername">Bob Benstro</b> <<a href="mailto:bbenstro@gmail.com">
bbenstro@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Could someone verify my config, at least?<br><br>
Thanks <div><span class="e" id="q_11177b7e27fde251_1"><br><br><br><div><span class="gmail_quote">On 3/20/07, <b class="gmail_sendername">Bob Benstro</b> <<a href="mailto:bbenstro@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
bbenstro@gmail.com</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Paul / Harald,<br><br>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.
<br><br>I'm seeing packets routed for <a href="http://192.168.15.90" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.15.90</a> 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.
<br><br>Packets left via the correct route, but were still PPPOE encapasuated but not IPSEC encrypted.<br><br>On this box I'm using the routing patches described on the <a href="http://lartc.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lartc.org</a> advanced routing howto (near the bottom of this page):
<br><br><a href="http://lartc.org/howto/lartc.rpdb.multiple-links.html#AEN298" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lartc.org/howto/lartc.rpdb.multiple-links.html#AEN298</a><br><br>
The link points to here:<br><br><a href="http://www.ssi.bg/%7Eja/#routes" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.ssi.bg/~ja/#routes</a><br><br>I'm using kernel <a href="http://2.6.17.7" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">2.6.17.7</a>.<br><br>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.
<br><br>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.
<br><br>Roadwarrior side:<br><br>config setup<br> nat_traversal=yes<br> nhelpers=0<br><br>include /etc/ipsec.d/examples/no_oe.conf<br><br>conn rw<br> dpdaction=restart<br> dpdtimeout=120<br> authby=rsasig
<br> pfs=no<br> keyingtries=3<br> left=%defaultroute <br> leftcert=/etc/ipsec.d/rw.pem<br> leftrsasigkey=%cert<br> right=<a href="http://1.1.1.1" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
1.1.1.1</a><br> rightcert=base.pem<br> rightsubnet=
<a href="http://192.168.0.0/24" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.0.0/24</a><br> auto=start<br><br>The 'base' has a more complex configuration, naturally:<br><br>config setup
<br> nat_traversal=yes<br> virtual_private=%v4:<a href="http://10.0.0.0/8,%25v4:172.16.0.0/12,%25v4:192.168.0.0/16,%25v4:%21192.168.2.0/24" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.2.0/24</a><br><br>conn %default<br> compress=yes<br> authby=rsasig<br> pfs=no<br> leftcert=base.pem<br> right=%any<br> rightca=%same
<br> rightrsasigkey=%cert<br> rightsubnet=vhost:%no,%priv<br> auto=add<br> keyingtries=3<br><br>#Disable Opportunistic Encryption<br>include /etc/ipsec.d/examples/no_oe.conf<br><br>conn internal
<br> left=<a href="http://192.168.0.1" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.0.1</a><br> leftprotoport=17/1701<br> rightprotoport=17/1701<br><br>conn cable1<br>
left=<a href="http://3.3.3.3" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">3.3.3.3</a><br> leftnexthop=
<a href="http://3.3.3.4" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">3.3.3.4</a><br> leftprotoport=17/1701<br> rightprotoport=17/1701<br><br>conn pppoe1<br> left=<a href="http://1.1.1.1" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
1.1.1.1</a><br> leftnexthop=<a href="http://1.1.1.2" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
1.1.1.2</a><br> leftprotoport=17/1701<br> rightprotoport=17/1701<br><br>conn pppoe2<br> left=<a href="http://2.2.2.2" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">2.2.2.2</a>
<br> leftnexthop=<a href="http://2.2.2.3" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">2.2.2.3</a><br> leftprotoport=17/1701
<br> rightprotoport=17/1701<br><br>conn internal10<br> left=<a href="http://10.10.10.1" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">10.10.10.1</a><br> leftprotoport=17/1701
<br> rightprotoport=17/1701<br><br>conn rw<br> auto=add<br>
left=<a href="http://1.1.1.1" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">1.1.1.1</a><br> leftnexthop=<a href="http://1.1.1.2" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
1.1.1.2</a><br> leftsubnet=<a href="http://192.168.0.0/24" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.0.0/24</a><br> rightnexthop=%defaultroute<br>
rightcert=rw.pem<br><br><br>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...
<br><br>Thanks (I hope!! ;) <div><span><br><br><br><br><div><span class="gmail_quote">On 3/16/07, <b class="gmail_sendername">Bob Benstro</b> <<a href="mailto:bbenstro@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
bbenstro@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div><span><span class="gmail_quote">On 3/16/07, <b class="gmail_sendername">Paul Wouters</b> <<a href="mailto:paul@xelerance.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
paul@xelerance.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, 16 Mar 2007, Bob Benstro wrote:<br><br>> > Most often this is due to the vpn server not being the default gateway, and<br>> > the local subnet sending the traffic for the vpn to the default gateway,<br>
> > instead of the vpn server.<br>> ><br>> ><br>> I'm not sure what you mean. It seems weird that you've removed from my<br>> quoted material above, the text that provides information showing this isn't
<br>> the case.<br><br>I did not see that information in your email.<br><br>> Anyhow, as I mentioned, the traffic is indeed leaving the correctly routed<br>> interface as it should be. The only problem is that the traffic leaving
<br>> that interface is not encrypted. It is, however, leaving the interface it<br>> should be leaving, in order to reach the remote box. My local subnet and<br>> its default route is not in question, as I am performing all tests on the
<br>> VPN box itself, so no need to worry there.<br><br>Okay. Are you sure the traffic leaves unencrypted? If you use KLIPS, that is<br>indeed easy to see, just compare outgoing physical interface with ipsecX<br>interface. With NETKEY, you don't get to see the encrypted packets before they
<br>leave your box, they are encrypted AFTER tcpdump can see them, so this cannot<br>be proven using the sending box. </blockquote></span><div><br><br>Hmm. Well, I'm using NETKEY, I haven't patched my kernel or anything of the sort. There is no ipsecX device for me.
<br><br>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.
<br><br></div><span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Since if they were cleartext, they would go<br>to some unknown private space and get dropped, you cannot see it on the receiving
<br>end either. But you might see encrypted packets arriving on the receiving end,<br>which are never successfully decrypted for some reason (NAT, ipsec passthrough<br>corruption, etc).</blockquote></span><div><br><br>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. :/
<br> </div><span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Then there is also the possibility you are in fact sending out encrypted ESP
<br>
packets (which you can't see when using NETKEY), but some filter somewhere filters<br>the ESP packets and they never arrive at the destination. Again, you would<br>not be able to easilly distinguish this from the case they are never encrypted,
<br>send to a bogus router and dropped.</blockquote></span><div><br><br>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?
<br><br>
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. :/
<br><br> </div><span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This is why I asked for more information. Knowing whether you use KLIPS or NETKEY
<br>on the sending end would help reduce the possible scenarios.<br><br></blockquote></span></div><br>
</blockquote></div><br>
</span></div></blockquote></div><br>
</span></div></blockquote></div><br>