[Solved]pfSense 2.4.3 Port Forwarding problem
-
Hi, for some reason i can't get the port forwarding to work, i'll post my configuration after a clean install of pfSense (proxmox VM),
basically, i can send packet to the web server listening on port 80 but it can't get out of the LAN, if i capture packet on the WAN interface i only get packets entering and nothing exiting, i don't know if this is the main problem but in fact i can't connect to any server on any port i tried. The VM hosting the server have internet access and it works if i try connecting with the local ip.
Thanks to everyone that helps me and as always i'm sorry for my not very good english.
-
-
I've already followed the troubleshooting procedure without any luck.
-
Then you probably didn't actually check everything.
Check the firewall on the target host.
Packet capture on the LAN. Does the SYN go to the host? Is there a response?
Make the Dest address of the port forward WAN address (like the 9987 port forward) and try again. I don't think any of the setup or troubleshooting guides tell you to use WAN net there.
Be sure you are testing from outside, like the troubleshooting docs say.
-
Well,
The firewall on the host is disabled, the SYN is sended and arrives to the server but the response doesn't reach the client(i'm testing from outside).
Oh, and WAN net is there because i was trying some things to see if it might work that way, normally i use WAN addr.
-
Port forwarding works. Every time when configured correctly.
Do you see the response in the packet capture on LAN? On WAN?
-
On the WAN the packets i get are:
IP my IP > 192.168.1.250.80(pfsense ip): tcp 0
IP 192.168.1.250.80 > my ip: tcp 0
and on the LAN:
IP *my ip * > 192.168.2.12.80(web server):tcp 0
IP 192.168.2.12.80 > my ip: tcp0there are only these packets repeated over and over.
my pfsense router is under another router but i enabled DMZ on the pfsense IP.
-
And what are they? Expand the views. If those are SYN followed by RST then the server is refusing the connection. Check the target server for the reason why. If they are SYN followed by SYN/ACK then something upstream is not passing the traffic because NAT is obviously working.
You can look at the last capture you took again by going back to Diagnostics > Packet Capture, setting the detail to full, and hitting View Capture.
-
I checked the packets and the SYN is followed by the ACK, so as you says there's something that's not passing the traffic, i'm sorry to bother you anymore but do you know something i could check that could cause this?
-
If the ACK is heading out WAN as it looks like it is, the next step would probably be to pcap on the client making the connection while pcapping on the WAN interface.
Looks like the NAT is working fine.
You could also check the MAC address on the traffic on the WAN interface to be sure the reply traffic is going to the right place.
-
I tried capturing packet from a client in the same subnet as pfsense and this is what is happening:
i don't really understand what is going on.
As for the MAC address, it's going to the correct interface.
-
192.168.1.250 talking to 192.168.1.200 would have ZERO to do with pfsense and or port forwarding at all.
Unless you have some really small network mask setup and those are different networks.. But /24 those are the same network and that traffic would have zero to do with pfsense.
-
192.168.1.250 is actually the pfsense VM ip, in fact the server is under the 192.168.2.0/24 subnet(it's small because i'll never surpass the 40VMs) that is managed by pfsense. 192.168.1.200 is just a client i'm using to test this.
-
well looks like you got some problem with your VM network then.. You mean that was your VM host IP, or pfsense actual IP on the 192.168.1/24
Why don't you actually draw up how you got things connected.. But pfsense is not involved in forwarding that traffic or firewalling it because its not crossing a router.. So the issue is at the network layer/nic not psfsense.
-
I would still like to see the MAC addresses for the SYN and SYN/ACK packets/frames instead of "As for the MAC address, it's going to the correct interface."
If you do post them, please detail exactly where the capture was taken.
-
This, is my network, i used only few computer but there are a bit more, the same with the VMs.
to make this work the NAT on the pfsense router should be working but it seems like the packets can't go back to the client.
-
This is the packet captured useing tcpdump on the WAN interface from the pfsense VM:
18:37:53.392279 9c:8e:99:f9:ee:5e > 22:09:ff:fe:cb:26, ethertype IPv4 (0x0800), length 74: 192.168.1.200.48564 > 192.168.1.250.80: Flags [S], seq 1150455616, win 29200, options [mss 1460,sackOK,TS val 2254887576 ecr 0,nop,wscale 7], length 0
18:37:53.393585 22:09:ff:fe:cb:26 > 9c:8e:99:f9:ee:5e, ethertype IPv4 (0x0800), length 74: 192.168.1.250.80 > 192.168.1.200.48564: Flags [S.], seq 1331495350, ack 1150455617, win 28960, options [mss 1460,sackOK,TS val 68786391 ecr 2254880506,nop,wscale 7], length 0the MAC address of the client is: 9c:8e:99:f9:ee:5e
I don't know if this helps but the WAN interface is actually a bridge(with only one interface) created with proxmox and it is not a direct passthrough.
-
OK then you need to figure out if that reply is making it back to the host. If not, why not and if so, what is the host doing with it? Looks like pfSense is doing everything it is supposed to be doing.
-
Ok, i don't know what happened but i switched the WAN interface with another physical interface and it started working.
At this point i thank you for helping me so much and i'll mark this thread as solved.
