<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>Hello, Bob</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>my question: do you have a POSTROUTING NAT rule in your
config?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>i had the same problem with a 2.6.19.1
kernel.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>i had a supernet nat rule, becaue of 3 192.168.X.X/24
subnets and made</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>a POSTROUTING NAT from 192.168.0.0/16 -> official
IP.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>The VPN did not work, since I made a</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>POSTROUTING -s 192.168.0.0/16 -d !
[REMOTE-IP-NET],</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>(important : the exclamation mark)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>so, what I did, is to exclude the the remote Subnet from my
source NAT.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>When i do not so, the traffic leaves the local box
unencrypted,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>and i is routed straight to the
internet.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>I think, there was i change in one of the 2.6 kernels with
NAT and NETKEY.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>king regards</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2>Harald</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=031015007-17032007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV><BR>
<DIV class=OutlookMessageHeader lang=de dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>Von:</B> users-bounces@openswan.org
[mailto:users-bounces@openswan.org] <B>Im Auftrag von </B>Bob
Benstro<BR><B>Gesendet:</B> Freitag, 16. März 2007 19:47<BR><B>An:</B> Paul
Wouters<BR><B>Cc:</B> users@openswan.org<BR><B>Betreff:</B> Re: [Openswan Users]
traffic only being encrypted one way<BR></FONT><BR></DIV>
<DIV></DIV><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="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">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="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">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="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">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="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">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></BODY><!--[object_id=#nestec.at#]--><FONT face=Tahoma size=2><FONT color=#0000ff>
<P align=center><FONT face=Tahoma size=2><FONT color=#0000ff><EM><STRONG>NESTEC - Die IT Security & Messaging Distribution mit Persönlichkeit<BR></STRONG></EM>GFi Software - BitDefender - NOD32 - BRICKS ISS - pdfMachine<BR>2X Terminal & ThinClient Solutions -Accunetix<BR>Besuchen Sie uns: www.nestec.at</FONT></FONT></P></FONT></FONT></HTML>