NAT forwarding into WireGuard Interface as LAN Interface
-
Hi,
this is a copy of WireGuard Interface as LAN Interface - NAT Traffic doesn't pass into, not sure which is the best point in forum...
My two pfSense instances are connected by official WireGuard package on both site.
Site-A is a vserver instance because of a static public network address is needed. On pfSense setup time here, only these interface was available and configured as WAN interface. The following WireGuard configuration established the second interface in the idea as LAN interface here.
Site-B is my home pfSense Firewall setup with all the knowing of my home networks.
All necessary routes and WireGuard networks are configured on both sites.The IPv4 (disabled IPv6) traffic is running in both directions via WireGuard tunnel as assumed, not only ICMP, "real traffic" by netcat too. In these test on Site-A netcat is running direct on pfSense, on Site-B on a server in a specific network segment at home.
BUT the "simple" test (netcat is running anywhere on a different internet server) to pass traffic on Site-A ingressed via WAN interface handled by a (logged) NAT forwarding rule destinated to a server on Site-B doesn't works.
The pfSense syslog on Site-A shows the logged and passed ingressed traffic on the WAN interface, but the Packet Capture here on Site-A shows already no ingress at the WireGuard interface, my LAN interface here.I would be very grateful for any assistance of my may be misunderstanding.
-
@Bronko said in NAT forwarding into WireGuard Interface as LAN Interface:
All necessary routes and WireGuard networks are configured on both sites.
Can you be more precise, please. Maybe you can post some screenshots.
-
@viragomann thanks a lot for your reply!
Site-A
tun_wg0: 10.200.0.2
netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire default xxxxxxxxxx UGS vtnet0 10.0.0.0/24 10.200.0.1 UGS tun_wg0 10.200.0.0/24 link#6 U tun_wg0 10.200.0.2 link#3 UHS lo0 xxxxxxxxx/22 link#1 U vtnet0 xxxxxxxxx link#3 UHS lo0 yyyyyyyyyyyyy link#1 UHS vtnet0 yyyyyyyyyyyyy link#1 UHS vtnet0 127.0.0.1 link#3 UH lo0 192.168.0.0/16 10.200.0.1 UGS tun_wg0
Site-B
tun_wg0: 10.200.0.1
netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire 0.0.0.0/8 link#12 U re0.8 default xxxxxxxxxxxxx UGS pppoe0 10.0.0.0/24 link#18 U re2.301 10.0.0.1 link#5 UHS lo0 10.0.1.0/24 link#21 U ovpns1 10.0.1.1 link#5 UHS lo0 10.0.2.0/24 link#25 U ovpns2 10.0.2.1 link#5 UHS lo0 10.0.3.0/24 link#22 U ovpns3 10.0.3.1 link#5 UHS lo0 10.0.4.0/24 link#23 U ovpns5 10.0.4.1 link#5 UHS lo0 10.0.5.0/24 link#24 U ovpns6 10.0.5.1 link#5 UHS lo0 10.200.0.0/24 link#8 U tun_wg0 10.200.0.1 link#5 UHS lo0 xxxxxxxxxxxxxx link#19 UH pppoe0 yyyyyyyyyyyyy link#5 UHS lo0 127.0.0.1 link#5 UH lo0 192.168.1.0/24 link#2 U re1 192.168.1.1 link#5 UHS lo0 192.168.2.0/30 link#1 U re0 192.168.2.2 link#5 UHS lo0 192.168.3.0/24 link#17 U re2.106 192.168.3.1 link#5 UHS lo0 192.168.6.0/24 link#20 U bridge0 192.168.6.1 link#5 UHS lo0 192.168.8.0/24 link#10 U re2.201 192.168.8.1 link#5 UHS lo0 192.168.9.0/24 link#16 U re2.105 192.168.9.1 link#5 UHS lo0 192.168.21.0/24 10.0.2.2 UGS ovpns2 192.168.178.0/24 10.0.4.2 UGS ovpns5 192.168.179.0/24 10.0.5.2 UGS ovpns6 zzzzzzzzzzzzzz link#19 UHS pppoe0
Server on Site-B (first post) located at 10.0.0.0/24
-
@Bronko
Do you masquerading on the WG interface at A (outbound NAT)?
If so, this should work already.However, if you don't and want to see the real source address on the server at B, you would need some additional settings.
-
This is currently (by default) configured for NAT outbound on Site-A
@viragomann said in NAT forwarding into WireGuard Interface as LAN Interface:
However, if you don't and want to see the real source address on the server at B, you would need some additional settings.
For final setup I plan to use HAProxy on Site-A with backend IPs on server net 10.0.0.0/24 on Site-B.
I'm wrong...? -
@Bronko
So you don't masquerading.For final setup I plan to use HAProxy on Site-A with backend IPs on server net 10.0.0.0/24 on Site-B.
This replaces the source IP anyway.
So configure the outbound NAT for masquerading at A even now.
Activate the hybrid mode, save this and add a new rule:
interface: tun_wg0 (or whatever the WG is)
protocol: TCP (or what you forward)
source: any
destination: the servers IP at B or an alias for multiple destination IPs
translation: interface address -
@viragomann you saved my day... thanks a lot!
On Site-B server /dev/null drains massive traffic currently... ;-) -
@viragomann said in NAT forwarding into WireGuard Interface as LAN Interface:
However, if you don't and want to see the real source address on the server at B, you would need some additional settings.
Beside HAProxy what would be your suggestion?
-
@Bronko
You mean, to get the public source IP on the server and get it work without masquerading?As mentioned, HAproxy does this anyway. Didn't ever configure it with forwarding across WG, but I guess it might use the WG interface IP as source. So it would be the same as your outbound NAT rule does and you'll can probably remove it.
Without masquerading you would have to assign an interface to the WG instance at B. I'll call it wg_sa here as exampel.
Then move over all firewall rules from the Wireguard tab to wg_sa.
Ensure the pass rule on wg_sa allow any source address to access the server.
There must be no pass rule on the Wireguard or on floating tab matching the forwarded traffic from A, otherwise the communication with the server will fail. -
@viragomann said in NAT forwarding into WireGuard Interface as LAN Interface:
Without masquerading you would have to assign an interface to the WG instance at B. I'll call it wg_sa here as exampel.
tun_wg0 is right in place on Site-B for sure, but you mean a second, Virtual IP interface there?
-
@Bronko
No. You should find tun_wg0 in Status > Interface. Then it's a dedicated interface. Otherwise you have to assign one. -
@viragomann said in NAT forwarding into WireGuard Interface as LAN Interface:
You should find tun_wg0 in Status > Interface. Then it's a dedicated interface.
Yes, it is already there due to the WireGurad setup.
Thanks @viragomann !
-
On Site-B at server net one machineMX is configured like these:
# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.200.0.2 0.0.0.0 UG 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.200.0.2 10.0.0.1 255.255.255.255 UGH 0 0 0 eth0 10.200.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 # ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0@if36: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 82:08:92:77:f8:80 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.0.0.102/24 brd 10.0.0.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::8008:92ff:fe77:f880/64 scope link valid_lft forever preferred_lft forever # ping 10.200.0.2 PING 10.200.0.2 (10.200.0.2) 56(84) bytes of data. 64 bytes from 10.200.0.2: icmp_seq=1 ttl=63 time=25.4 ms 64 bytes from 10.200.0.2: icmp_seq=2 ttl=63 time=25.5 ms 64 bytes from 10.200.0.2: icmp_seq=3 ttl=63 time=25.3 msBut outgoing internet traffic doesn't goes through Site-A tun_wg0: 10.200.0.2
# curl ifconfig.me curl: (7) Failed to connect to ifconfig.me port 80 after 3093 ms: No route to hostHAproxy on Site-A managed incoming traffic as awaited, but on machineMX initiated internet connections (like postfix) on Site-B should go on WAN interface at Site-A.
Outbound NAT for masquerading at Site-A for servers IP at Site-B temporarily (HAproxy doesn't need it as you mentioned above) activated, but doesn't changed the behavior.
There are some routing/gateway configuration steps in Site-B still open for these scenario?
Do you have some hints here too?
-
@Bronko TLDR but I have that running now, what you have described at first and I don't see any problems. I don't NAT anything inside this whole network, only towards public addresses on WAN.
Also make sure that on B the peer-config off A has 0.0.0.0/0 as allowed IPs and that in A all the routes are set in System-Routing-Static Routes. -
@Bob-Dig said in NAT forwarding into WireGuard Interface as LAN Interface:
Also make sure that on B the peer-config off A has 0.0.0.0/0 as allowed IPs...
That was missing!
Thanks to @Bob-DigBut machineMX doesn't knows anymore tun_wg0: 10.200.0.2 for routing (DNS only), solved by Policy Routing on Site-B as described here for ex.
-
@Bob-Dig said in NAT forwarding into WireGuard Interface as LAN Interface:
@Bronko TLDR but I have that running now, what you have described at first and I don't see any problems. I don't NAT anything inside this whole network, only towards public addresses on WAN.
Routing is fine, but I have to see the source IP address of sending mail server at the internet on machineMX on Site-B server net (10.0.0.0/24). Currently the 10.200.0.2 (tun_wg0) is present because of NAT.
@viragomann said in NAT forwarding into WireGuard Interface as LAN Interface:
This replaces the source IP anyway.
You are right, the source IP is replaced by 10.200.0.2 (tun_wg0). How to avoid it?
Any hints for me?
-
@Bronko said in NAT forwarding into WireGuard Interface as LAN Interface:
Any hints for me?
Don't NAT, like I said before and don't use haproxy for email.
-
@Bronko said in NAT forwarding into WireGuard Interface as LAN Interface:
This replaces the source IP anyway.You are right, the source IP is replaced by 10.200.0.2 (tun_wg0). How to avoid it?
HAproxy has to replace the source IP with its outgoing interface IP to get the routing work reliably.
You can avoid this though by enabling the transparent mode in the concerned backend settings. But I don't know if the routing across the VPN will work properly then.
Anyway you would have to obey my suggestions regarding interface assignment and filter rules at B above.If it's a http frontend it's rather recommended to add a forward-for header, which would get the clients IP as value. However, the backend server would have to interpret this to get the client IP in the log.
-
@Bob-Dig said in NAT forwarding into WireGuard Interface as LAN Interface:
Don't NAT, like I said before and don't use haproxy for email.
That is what I have learned here, using haproxy for SMTP isn't comfortable...
Therefore I have been already created a forwarding rule for WAN on Site-A to machineMX on Site-B server net (10.0.0.0/24) and re-configured the mapping suggested by:
@viragomann said in NAT forwarding into WireGuard Interface as LAN Interface:
So configure the outbound NAT for masquerading at A even now.
Activate the hybrid mode, save this and add a new rule:
interface: tun_wg0 (or whatever the WG is)
protocol: TCP (or what you forward)
source: any
destination: the servers IP at B or an alias for multiple destination IPs
translation: interface addressby the option Do not NAT. But these option breaks the traffic flow, no more connection from outside to SMTP on machineMX.
What I have to learn here...?
-
@Bronko said in NAT forwarding into WireGuard Interface as LAN Interface:
by the option Do not NAT. But these option breaks the traffic flow, no more connection from outside to SMTP on machineMX.
I didn't mention that option.
And the NAT might be superfluous if you're driving this traffic over HAproxy, as mentioned. The suggestion was meant for the time to be.
