Hello Mitja,

Le 05/02/2013 22:36, Mitja Muženič a écrit :
I'm the author of the article you quoted.


Your article is really great, I'm glad to get some help from you :)


Do you have a default gateway? IPsec on OpenBSD behaves weirdly if you don't
have one (even if it's not needed!). This scenario is likely to happen
especially in the test setups with directly connected firewalls...


Yes, I have one. In fact this is not a lab setup. I'm doing the test in production environment. I can break it as this is not a site of great importance. The two sites are connected via the Internet.


The trick is that both ipsec tunnel perform a sanity check on the address
range of the traffic. On this side the tunnel is between 192.168.0/24 and
192.168.6/24 [1], but we tell the peer that he ought to establish a tunnel
from _his_ 192.168.0/24 to 192.168.7/24 [2]. So your traffic from the remote
192.168.0.1 to 192.168.7.1 fails the source check on this end, as there is
no NAT on remote device and this side sees traffic from 192.168.0.1, not
192.168.6.1 as defined by the tunnel [1], so it's silently discarded. If you
try to bypass this by pinging from 192.168.6.1 to 192.168.7.1, such traffic
won't match the remote site's source tunnel definition [2] and will be
dropped on the remote end already before even entering the tunnel.


It isn't clear to me. There is NAT on remote the device and I can see traffic from 192.168.6.1.

There shouldn't be any traffic from 192.168.x.0 on your em0, that's your
public interface, isn't it? I presume this comes from you actually testing
this in a lab and em0 is actually directly connected to the remote device?
So the private traffic on em0 is leakage from far side because that traffic
does not enter the vpn tunnel at all.


em0 is my public facing interface and it is connected to an ISP that route traffic to the other site.


This is unexpected, you should be seeing icmp echo from 192.168.7.1 to
192.168.6.1. Double check that your "match on enc0..." rules really apply to
those packets, I've been bitten by the "match" logic before. For test
purposes you can always rewrite that rule to "pass out quick on enc0...".
Also see that you don't have a "set skip on enc0" line.


I don't for sure. The whole pf.conf was posted at the top of the first mail. There is nothing more than the first "match" rule. I'm pretty sure the problem lies with PF, can't see where for now but I'm still searching.

Thank you very much for the answer.
Denis

Reply via email to