[Openswan Users] traffic only being encrypted one way

[Harald Scharf]

Hello, Bob
 
my question: do you have a POSTROUTING NAT rule in your config?
i had the same problem with a 2.6.19.1 kernel.
 
i had a supernet nat rule, becaue of 3 192.168.X.X/24 subnets and made
a POSTROUTING NAT from 192.168.0.0/16 -> official IP.
The VPN did not work, since I made a
 
POSTROUTING -s 192.168.0.0/16 -d ! [REMOTE-IP-NET],
(important : the exclamation mark)
 
so, what I did, is to exclude the the remote Subnet from my source NAT.
When i do not so, the traffic leaves the local box unencrypted,
and i is routed straight to the internet.
 
I think, there was i change in one of the 2.6 kernels with NAT and NETKEY.
 
king regards
 
Harald
 
 

  _____  

Von: users-bounces at openswan.org [mailto:users-bounces at openswan.org] Im Auftrag von Bob Benstro
Gesendet: Freitag, 16. März 2007 19:47
An: Paul Wouters
Cc: users at openswan.org
Betreff: Re: [Openswan Users] traffic only being encrypted one way




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.
	
	



NESTEC - Die IT Security & Messaging Distribution mit Persönlichkeit
GFi Software - BitDefender - NOD32 - BRICKS ISS - pdfMachine
2X Terminal & ThinClient Solutions -Accunetix
Besuchen sie uns: www.nestec.at


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20070317/9e4ae55e/attachment-0001.html