On Wed, Jun 28, 2023 at 09:53:38AM +0200, Jiri Navratil wrote: > 3) The sites I'm configuring are both using PPPoE. One have VLAN and I > see external statical IPv4 on PPPoE, but other site uses NAT 1:1, so I > see private IPv4 on PPPoE, but I have to access it over allocated > external IPv4. I'm not sure, which IP comes where. I switched responder > and initiator, to have responder on site with VLAN, but anyway I'm not > sure, where in pf.conf and /etc/iked.conf use external and where NAT IP.
Flow source/destination IPs must exactly match packets leaving the box. So you will either need to put the private IP as the from "src" of the flow (which can be annoying if it changes at run-time, you need to adjust and reload flows somehow when the private IP changes) or use "any" as source with the other end's static public IP as the destination (and be careful with your flow traffic selectors if you still need to send some traffic towards the other side without IPsec). Flows towards a box behind NAT need to use the NAT's public IP to match outgoing packets sent towards the internet. You can ignore 'srcnat' in this context. 'srcnat' could be used later to NAT traffic which crosses the tunnel, once the tunnel is working. > 4) Using enc0 in pf.conf not worked. I had to switch to pppoe. Is that > correct? No rules for enc0 and vlan? You can just set skip on enc0 until it is working. Filtering on enc0 is only needed if you want to prevent some traffic matched by flows from crossing the tunnel (depending on the situation, adjusting flows to avoid matching the unwanted traffic in the first place might be better). > 4) I don't see any output from nc and tcdump commands. How I can see, > which pf rule stops ping from other site? Because one side is behind NAT the ESP packets should automatically be encapsulated in UDP (ESP by itself cannot cross NAT). You should see UDP packets on port 4500 (ipsec-nat-t) being exchanged, both during handshakes and during regular operation of the tunnel. These UDP packets need to pass all the way through for things to work. > 5) There is note in FAQ, that Native WireGuard support is also > available. As both IPsec and WireGuard are new to me, may wg(4) be an > option? Yes, you can try it as an alternative. It can be easier to get going across NAT since external IP addresses don't matter to Wireguard. Wireguard only cares about whether incoming packets have been signed with the correct key.
