<br>Paul / Harald,<br><br>Finally managed to get a hub hooked up today.&nbsp; The packets I&#39;m now seeing are PPPOE encapsulated, so, I know I&#39;m looking at things via tcpdump after it&#39;s left for the modem.. and openswan should have done its work.
<br><br>I&#39;m seeing packets routed for <a href="http://192.168.15.90">192.168.15.90</a> over the net, as I described before. :/&nbsp; Something is definitely wonky here.&nbsp; Just to be sure, I removed all iptables rules, removed all routes, and started with a fresh routing table.&nbsp; 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&#39;m using the routing patches described on the <a href="http://lartc.org">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">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/~ja/#routes">
http://www.ssi.bg/~ja/#routes</a><br><br>I&#39;m using kernel&nbsp; <a href="http://2.6.17.7">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.&nbsp; It is only when I have gone into a linux to linux setup that problems exist.&nbsp; 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&nbsp; 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.&nbsp; Still, I flushed all routes via ip route flush, and iptables via -F, and confirmed they had vanished.&nbsp; This should not be the cause, then.
<br><br>Roadwarrior side:<br><br>config setup<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nat_traversal=yes<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nhelpers=0<br><br>include /etc/ipsec.d/examples/no_oe.conf<br><br>conn rw<br>&nbsp;&nbsp;&nbsp; dpdaction=restart<br>&nbsp;&nbsp;&nbsp; dpdtimeout=120<br>&nbsp;&nbsp;&nbsp; authby=rsasig
<br>&nbsp;&nbsp;&nbsp; pfs=no<br>&nbsp;&nbsp;&nbsp; keyingtries=3<br>&nbsp;&nbsp;&nbsp; left=%defaultroute&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; leftcert=/etc/ipsec.d/rw.pem<br>&nbsp;&nbsp;&nbsp; leftrsasigkey=%cert<br>&nbsp;&nbsp;&nbsp; right=<a href="http://1.1.1.1">1.1.1.1</a><br>&nbsp;&nbsp;&nbsp; rightcert=base.pem<br>&nbsp;&nbsp;&nbsp; rightsubnet=
<a href="http://192.168.0.0/24">192.168.0.0/24</a><br>&nbsp;&nbsp;&nbsp; auto=start<br><br>The &#39;base&#39; has a more complex configuration, naturally:<br><br>config setup<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nat_traversal=yes<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; virtual_private=%v4:<a href="http://10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.2.0/24">
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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; compress=yes<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authby=rsasig<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pfs=no<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftcert=base.pem<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; right=%any<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rightca=%same
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rightrsasigkey=%cert<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rightsubnet=vhost:%no,%priv<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto=add<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; keyingtries=3<br><br>#Disable Opportunistic Encryption<br>include /etc/ipsec.d/examples/no_oe.conf<br><br>conn internal
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; left=<a href="http://192.168.0.1">192.168.0.1</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftprotoport=17/1701<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rightprotoport=17/1701<br><br>conn cable1<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; left=<a href="http://3.3.3.3">3.3.3.3</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftnexthop=
<a href="http://3.3.3.4">3.3.3.4</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftprotoport=17/1701<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rightprotoport=17/1701<br><br>conn pppoe1<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; left=<a href="http://1.1.1.1">1.1.1.1</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftnexthop=<a href="http://1.1.1.2">
1.1.1.2</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftprotoport=17/1701<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rightprotoport=17/1701<br><br>conn pppoe2<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; left=<a href="http://2.2.2.2">2.2.2.2</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftnexthop=<a href="http://2.2.2.3">2.2.2.3</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftprotoport=17/1701
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rightprotoport=17/1701<br><br>conn internal10<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; left=<a href="http://10.10.10.1">10.10.10.1</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftprotoport=17/1701<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rightprotoport=17/1701<br><br>conn rw<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto=add<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; left=<a href="http://1.1.1.1">1.1.1.1</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftnexthop=<a href="http://1.1.1.2">1.1.1.2</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftsubnet=<a href="http://192.168.0.0/24">192.168.0.0/24</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rightnexthop=%defaultroute<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rightcert=rw.pem<br><br><br>I&#39;m not sure where else to go from here.&nbsp; Keep in mind, as review, the connection does come up and works perfectly from the road warrior side.&nbsp; 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!! ;) <br><br><br><br><div><span class="gmail_quote">On 3/16/07, <b class="gmail_sendername">Bob Benstro</b> &lt;<a href="mailto:bbenstro@gmail.com">bbenstro@gmail.com</a>&gt; 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 class="q"><span class="gmail_quote">On 3/16/07, <b class="gmail_sendername">Paul Wouters</b> &lt;<a href="mailto:paul@xelerance.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
paul@xelerance.com</a>&gt; 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>&gt; &gt; Most often this is due to the vpn server not being the default gateway, and<br>&gt; &gt; the local subnet sending the traffic for the vpn to the default gateway,<br>

&gt; &gt; instead of the vpn server.<br>&gt; &gt;<br>&gt; &gt;<br>&gt; I&#39;m not sure what you mean.&nbsp;&nbsp;It seems weird that you&#39;ve removed from my<br>&gt; quoted material above, the text that provides information showing this isn&#39;t
<br>&gt; the case.<br><br>I did not see that information in your email.<br><br>&gt; Anyhow, as I mentioned, the traffic is indeed leaving the correctly routed<br>&gt; interface as it should be.&nbsp;&nbsp; The only problem is that the traffic leaving
<br>&gt; that interface is not encrypted.&nbsp;&nbsp;It is, however, leaving the interface it<br>&gt; should be leaving, in order to reach the remote box.&nbsp;&nbsp; My local subnet and<br>&gt; its default route is not in question, as I am performing all tests on the
<br>&gt; 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&#39;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.&nbsp; Well, I&#39;m using NETKEY, I haven&#39;t patched my kernel or anything of the sort.&nbsp; 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.&nbsp; This lead me to believe that I should be able to see encrypted packets, but fair enough.
<br><br></div><span class="q"><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>&nbsp;</div><span class="q"><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&#39;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?&nbsp; 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.&nbsp; 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.&nbsp; Blech. :/
<br><br>&nbsp;</div><span class="q"><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>