Solved Can't get NAT working with pf on FreeBSD 13.1

I have this working. I used a different subnet because 10.55.1.0/24 is already in use.

The jails on the portal host (proxy01 was created for this test).

Code: 
[r720-02 dan ~] % jls
   JID  IP Address      Hostname                      Path
     4  127.163.54.32   r720-02-pg01.int.unixathome.o /jails/pg01
     5  127.163.0.10    r720-02-ingress01.int.unixath /jails/ingress01
     6  127.163.0.80    r720-02-nginx01.int.unixathom /jails/nginx01
     8  10.200.0.1      r720-02-proxy01.int.unixathom /jails/proxy01

The ping started from inside the jail:

Code: 
root@r720-02-proxy01:/ # ping 10.55.0.24
PING 10.55.0.24 (10.55.0.24): 56 data bytes
64 bytes from 10.55.0.24: icmp_seq=0 ttl=62 time=9.688 ms
64 bytes from 10.55.0.24: icmp_seq=1 ttl=63 time=9.785 ms
64 bytes from 10.55.0.24: icmp_seq=2 ttl=63 time=8.643 ms
64 bytes from 10.55.0.24: icmp_seq=3 ttl=63 time=10.155 ms
64 bytes from 10.55.0.24: icmp_seq=4 ttl=63 time=9.539 ms

On wg0 traffic on the basement host:

Code: 
22:12:08.909897 IP 10.55.0.24 > 10.200.0.1: ICMP echo reply, id 807, seq 156, length 64
22:12:09.972576 IP 10.200.0.1 > 10.55.0.24: ICMP echo request, id 807, seq 157, length 64
22:12:09.972726 IP 10.55.0.24 > 10.200.0.1: ICMP echo reply, id 807, seq 157, length 64

tcpdump on the host being pinged:

Code: 
[slocum dan ~] % sudo tcpdump -ni ix2 host 10.55.0.24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ix2, link-type EN10MB (Ethernet), capture size 262144 bytes
22:12:01.602600 IP 10.200.0.1 > 10.55.0.24: ICMP echo request, id 807, seq 149, length 64
22:12:01.602658 IP 10.55.0.24 > 10.200.0.1: ICMP echo reply, id 807, seq 149, length 64

I added this on the gateway host at home route add 10.200.0.0/24 10.55.0.59

I adjusted the AllowedIPs on the basement Wireguard configuration to add 10.200.0.0/24
 
It looks good. If have many hosts in your local site that need to be accessed from remote site it will be time consuming to add a static route on each of them to 10.200.0.0/24 so instead of that can you try to add this static route to the router on 10.55.0.1 this way every local host should be able to reach the remote network via it's default route 0.0.0.0 10.55.0.1.

It's not the best solution because the traffic from 10.55.0.0/24 to 10.200.0.0/24 will look like this:
10.55.0.24 -> 10.55.0.1 -> 10.55.0.59 -> 10.9.1.146 - > 10.200.0.0/24
And return traffic will come from:
10.200.0.0/24 -> 10.9.1.145 -> 10.55.0.59-> 10.55.0.24

That's why it's preferred this VPN tunnel to be on the router itself 10.55.0.1 instead of some internal host like now.
 
The vpn tunnel network address is 10.9.1.144/30 not 10.9.1.146/30 as pointed in your blog.
Remove or mask the private key in server config section and client config section.

A simple network diagram https://app.diagrams.net/ can visualize your network and make it much easy to understand. Draw.io also have option to export the diagram in cool html format.
example
 
VladiBG said:
The vpn tunnel network address is 10.9.1.144/30 not 10.9.1.146/30 as pointed in your blog.
Click to expand...

I’ll fix that soon.

VladiBG said:
Remove or mask the private key in server config section and client config section.
Click to expand...

Those keys are no longer in use. They have also been modified and will not work as shown. This is noted somewhere in the post.

I’m torn between making the examples easy to follow and making them realistic.

Mind you: “server-public-key” is easier to understand than dW86sGXillGbv00tACtLMxoUjBf5hyCR6aQF0+cnimI=
 
You must log in or register to reply here.
Back
Top