[Solved] Port Forwarding Across IPsec Tunnel
-
Hello! I have four pfSense routers in various locations all connected to each other with IPsec tunnels (diagram attached). Some have static IPs, some have dynamic, some have private. Sometimes I want to run a service on a static IP but the site it's at doesn't have a static. I want to be able to port forward from a router with a public IP to another LAN. For example, I have a static on the public cloud router. I created a port forwarding rule to forward a port to an IP behind the lab router. It won't work unless I also get the default gateway on the lab router to the IPsec tunnel gateway and create a policy route on the lab router for all traffic from the vm to go over the IPsec. Does anyone have any good ideas to fix this? I was thinking OpenVPN but then my performance will drop dramatically.
-
@MeCJay12
Hello.
The problem is that the "reply-to" function does not work on PF on virtual interfaces ( VTI,GRE,OpenVPN). This means that external traffic coming through the virtual tunnel will only come back through the default gateway.
To solve this problem you need to use the NAT Outbound on the VTI interface of the public Cloud router. -
Thanks for you reply. When you say I need NAT Outbound you mean like an Outbound NAT rule? I built a rule that is Source any, Dest. the IP and port of my service I want to forward, and interface VTI int (not IPsec int) that didn't work. Also, do I need to leave the policy route in the Lab router?
-
@MeCJay12
In such cases I give an example of iptables Linux- use port forwarding
37.xxx.xxx.xxx = ip address of WAN interface Public Cloud
192.168.1.230 = ip address of internal server (behind lab router)
*nat :PREROUTING ACCEPT [0:0] -A PREROUTING -d 37.XXX.XXX.XXX -p tcp -m multiport --destination-port 25,465,587,993 -j DNAT --to-destination 192.168.1.230
- use NAT Outbound
tun100 - VTI tunnel interface
10.10.100.2 - ip address of VTI interface (Public Cloud side )
:POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A POSTROUTING -o tun100 -p tcp -m multiport --destination-port 25,465,587,993 -d 192.168.1.230 -j SNAT --to-source 10.10.100.2
- use port forwarding
-
That's what I have setup but that doesn't seem to be working for me. Picture of the config incase I'm just being dumb.
-
@MeCJay12
Try using "packet capture" on the VTI Public Cloud interface to make sure port forwarding and outbound nat work correctly .tcpdump -netti enp0s20f0 tcp and '(port 25 or port 465 or port 587 or port 993)' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp0s20f0, link-type EN10MB (Ethernet), capture size 262144 bytes ethertype IPv4 (0x0800), length 74: 209.85.208.169.35890 > 37.XXX.XXX.XXX.smtp: Flags [S], seq 1690528637, win 62920, options [mss 1430,sackOK,TS val 1702238047 ecr 0,nop,wscale 8], length 0 ethertype IPv4 (0x0800), length 74: 37.XXX.XXX.XX.smtp > 209.85.208.169.35890: Flags [S.], seq 1994327853, ack 1690528638, win 14480, options [mss 1346,sackOK,TS val 2138448145 ecr 1702238047,nop,wscale 7], length 0
[root@es ~]# tcpdump -netti tun100 tcp and '(port 25 or port 465 or port 587 or port 993)' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun100, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes Out ethertype IPv4 (0x0800), length 76: 10.10.100.2.35890 > 192.168.1.230.smtp: Flags [S], seq 1690528637, win 62920, options [mss 1360,sackOK,TS val 1702238047 ecr 0,nop,wscale 8], length 0 In ethertype IPv4 (0x0800), length 76: 192.168.1.230.smtp > 10.10.100.2.35890: Flags [S.], seq 1994327853, ack 1690528638, win 14480, options [mss 1346,sackOK,TS val 2138448145 ecr 1702238047,nop,wscale 7], length 0
-
Yeah, I had run a pcap after a made the rule to make sure it was working.
-
-
It worked for me when I downloaded it. Here's a pic.
-
@MeCJay12
I can see that there are no answers from host 192.168.2.8
If everything is configured correctly, then you need to check the lab router
Also using tcpdump .
192.168.255.229 is the ip address of the VTI interface (Public cloud)? -
Absolutely dumb: Ubuntu enabled ufw in the background after an update.