Port Forwarding Trouble
-
Hey Guys,
I am hoping someone can help point me in the right direction when it comes to port forwarding. I am trying to port forward port 443 to an nginx server I have running within a vlan on the Netgate 2100 model.
Version: 21.02-RELEASE-p1
My home ISP is ATT and within their Gateway settings I have enabled the IP Passthrough to pass all traffic to the WAN Interface on the Pfsense box. This seems to be working correctly:
I then plugged an ESX server into Switch Port 3 on the Netgate 2100 device. Connection was established and then I went through the below steps to setup the vlan:
I am able to spin up a VM within this vlan (192.168.200.11), it is able to reach other servers within the vlan and make outbound connections to the internet, so initially all connection seems fine. I am wanting this to serve as an reverse proxy and am using NGINX to do so. The server is listening on port 443:
I want this to be publicly accessible so I tried to create the below NAT rule:
The corresponding firewall rule is also created:
However, I cannot connect to it from the public internet
With some troubleshooting, I ran tcpdump on the WAN interface of Pfsense and I see the connection attempts hitting the interface, yet the WAN interface does not seem to be passing the traffic to the internal host on the Server vlan.
When running the "Test Port" tool within the Web GUI, I get connection failures to that host and port from the WAN interface:
However, other Source Addresses (such as the LAN interface) can establish a connection with that host and port:
I have spent a few days on this and for the life of me cannot figure out what steps I may have missed. I am wondering if it is something with how the vlans are configured but I am not sure.
Any help or insight would be greatly appreciated!
Thanks,
Taylor -
@twalton23 IIRC you can't forward tcp/443 if you have pfSense WebGUI listening on that port. Change WebGUI to 444 or something else and then test your port-forward again.
-
@kom Hey Kom, thanks for replying. I have already changed the Web Gui to port 8080... I did just discover something else. I got shell onto the pfsense box and ran a traceroute to the internal server from the WAN interface. I see that it is trying to reach the internal IP of the ATT Gateway which seems odd:
Is there a way to statically set a route to this host that takes the gateway of the vlan (192.168.200.1)?
-
@twalton23 You shouldn't have to do anything with regard to static routes. It should just work. Next step is to do a packet capture on WAN and vlan20 to check that the incoming packets are hitting your WAN, being processed and spit out the vlan to your server.
Troubleshooting NAT Port Forwards
Edit; Is your WAN in private IP space? Your modem shouldn't be in the equation at all. It should act as a bridge and nothing more.
-
@kom Hey Kom, the WAN is in the public space.
I have the WAN interface on the Pfsense box set to the Public IP given to me by ATT. I also have their Gateway as the Gateway for my WAN IP. When I run a traceroute from the WAN interface to 192.168.200.11, the first hop is the private IP of the ATT Gateway that is in the house.
Which is odd, cause I cannot connect to their Web UI hosted on 192.168.1.254 unless I take pfsense out of the mix.
Tcpdump output of WAN interface during traceroute:
The 104.181.152.45 is the public ip assigned to my WAN interface.
Output of TCPDUMP on vlan interface that serves the 192.168.200.1/24 network:
So for some reason it seems like pfsense is trying to route to 192.168.1.254 (private ip of ATT Gateway that is out of the mix) to get to 192.168.200.11 and I am not sure why
-
@twalton23 Simplify this test by using Diagnostics - Packet Capture on WAN and filter by your test address then try to access your server from the client. Then run it again on your vlan20 and filter by your server address and try access again. That will filter out the arp traffic and other crap we're not interested in.
-
You can't test like that using the WAN. The route-to rules will force and traffic sourced from the WAN IP via it's gateway if there is one defined on the interface.
You can try sourcing from another interface to check the target is responding to anything outside it's own subnet. The VLAN 10 interface maybe.
Steve
