<br><br><div><span class="gmail_quote">On 3/16/07, <b class="gmail_sendername">Paul Wouters</b> <<a href="mailto:paul@xelerance.com">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><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><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><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><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><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><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></div><br>