NAT doesn't work for server inside VLAN after NIC change
-
hello gents,
i have been trying to solve this problem for a solid 4 hours now, to no avail. any help is appreciated. here goes:
my network looks like this: WAN - Modem (bridge mode) - managed switch < - > pfsense ( 2.4.4-RELEASE-p3 )
most of my clients are virtual, the VM host is connected to the switch via LAGG. i have two subnets:
192.168.1.0/24
192.168.5.0/24 (VLAN 5)each subnet has (among other things) one client that is to be accessed via VNC.
today i replaced the intel NIC in my pfsense box with another model, which has 4 ports instead of 2. the goal was to create a another LAGG connection, in this case from the pfsense box to the switch. i swapped the NICs, reconfigured everything in pfsense, established the LAGG, the VLAN, etc.
everything works like before, except i cannot access the VM whithin VLAN5 with a VNC viewer anymore. the vm itself has internet access and x11vnc (it's a linux machine) is running and ready.
pfsense is configured to
forward port 5900 to 192.168.1.10:5900 (machine #1, NAT is working perfectly)
forward port 5901 to 192.168.5.2:5900 (machine in question,NAT isn't working)my NAT / WAN rules look like this:
using a port checker, i can see that port 5900 is correctly detected as "open", but 5901 isn't. packet capture shows packets entering the WAN interface, but nothing in VLAN5. firewall log shows the 5901 requests being blocked by the "default deny" rule.
so far i have tried:
-rebooting everything
-using different ports
-automatically / manually create rules
-switching client IP addresses
-clearing states
-i also followed all the steps in the "nat troubleshooting" doci don't know what else to do, and it is probably something really trivial that i've overlooked. so thanks in advance!
-
@DJS4000 said in NAT doesn't work for server inside VLAN after NIC change:
-i also followed all the steps in the "nat troubleshooting" doc
If that the case you would have figured out your problem already.. If the traffic is getting to pfsense.. But blocked by default deny then you have a rule blocking it..
Please post up your actual full set of wan rules.
Your what assume is wan rules there showing 192.168.5.2 rule with hits on it would of mean that rule allowed traffic.
What I have found is users loose track of what they are trying and don't really understand what is going on and just clicking shit tend to miss what is causing the problem.
In the guide you followed, when you sniff, you sniffed on the lan side of pfsense and saw or didn't see it send on.. If your saying blocked then it would of never been sent.. But your rule would not of shown the 150B of being allowed either... So thinking you have different symptoms for different things..
Please the rules auto do them port forward, show your full wan rules... And then sniffing on wan and lan side of your testing.
-
hi john, and thanks for the advice. like i said, my brain has gotten a bit mushy over the last few hours. anyway, here are all my wan rules:
sniffing port 5901 produces this:
tcp In 109.40.66.169:8807 192.168.5.2:5900 CLOSED:SYN_SENT 00:00:03 00:00:28 2 120
which is strange, because the machine is definitely up, running and listening.
-
So that was sniffed on lan side, clearly pfsense sent the traffic on... But you see no response at all? Or did it send back RST? You only got that one entry in your sniff.
That is showing your port forwards are working and pfsense is doing what you told it to do.. If the machine does not answer, or has a firewall, or maybe sending traffic to some other gateway other than pfsense.. That is not on pfsense.
btw: side note - I would not in MILLION years open up vnc to the public internet.. You have a vpn server running.. if you need to remote to a box from internet - then vpn in..
-
the vnc viewer just aborts with "connection closed unexpectedly". yes i know it's dangerous, but the server only runs when needed and only for short time periods.
here is the output from tcpdump listening in on the WAN uplink, port 5901:
listening on pppoe0, link-type NULL (BSD loopback), capture size 262144 bytes 19:32:26.424192 IP ip-109-40-66-169.web.vodafone.de.1881 > <public_ip>.5901: UDP, length 500 19:32:26.469409 IP ip-109-40-66-169.web.vodafone.de.22606 > <public_ip>.5901: Flags [S], seq 3205670012, win 29200, options [mss 1452,sackOK,TS val 597147393 ecr 0,nop,wscale 5], length 0 19:32:26.843120 IP ip-109-40-66-169.web.vodafone.de.1881 > <public_ip>.5901: UDP, length 500 19:32:27.471162 IP ip-109-40-66-169.web.vodafone.de.22606 > <public_ip>.5901: Flags [S], seq 3205670012, win 29200, options [mss 1452,sackOK,TS val 597148396 ecr 0,nop,wscale 5], length 0 19:32:27.842352 IP ip-109-40-66-169.web.vodafone.de.1881 > <public_ip>.5901: UDP, length 500 5 packets captured 247 packets received by filter 0 packets dropped by kernel
and the same thing for 5900 on the same interface:
listening on pppoe0, link-type NULL (BSD loopback), capture size 262144 bytes 19:39:09.002918 IP ip-109-40-66-169.web.vodafone.de.29195 > betclient.vault.31.5900: Flags [S], seq 642356159, win 29200, options [mss 1452,sackOK,TS val 597549927 ecr 0,nop,wscale 5], length 0 19:39:10.002646 IP ip-109-40-66-169.web.vodafone.de.29195 > betclient.vault.31.5900: Flags [S], seq 642356159, win 29200, options [mss 1452,sackOK,TS val 597550928 ecr 0,nop,wscale 5], length 0 19:39:21.003037 IP ip-109-40-66-169.web.vodafone.de.29195 > betclient.vault.31.5900: Flags [R.], seq 642356160, ack 0, win 0, length 0 19:39:21.392341 IP ip-109-40-66-169.web.vodafone.de.11878 > betclient.vault.31.5900: Flags [S], seq 968125562, win 29200, options [mss 1452,sackOK,TS val 597562317 ecr 0,nop,wscale 5], length 0 19:39:22.394531 IP ip-109-40-66-169.web.vodafone.de.11878 > betclient.vault.31.5900: Flags [S], seq 968125562, win 29200, options [mss 1452,sackOK,TS val 597563320 ecr 0,nop,wscale 5], length 0 5 packets captured 337 packets received by filter 0 packets dropped by kernel
which translates to the correct host but gets no response.
i'm starting to think the VM is the problem.
-
So your dest has a firewall, or its using a different gateway. Figure out which.
Pfsense clearly sent the traffic on.. Other thing is that is not the right IP where vnc is running? Or vnc not running?
Your port forward is working.. Nothing pfsense can do if dest doesn't answer.
-
ok, apparently it's not that simple. i switched the VM to the main subnet (x.x.1.x) and vnc works immediately. the machine is reachable from within the subnet and from remote. there must be some config hijinks that i am missing here :(
what is going on? maybe i should perform a fresh install of pfsense?
edit: it works. i don't known how and why, but after deleting all configurations and redoing everything for literally the 12th time it suddenly works again. i have absolutely no idea why.
but anyway, thanks @johnpoz , appreciate the support!
-
It's not pfSense.
Packet capture on the inside interface for
Host: 192.168.5.2
Port: 5900Do you see the traffic? If so then everything is working on the firewall. The connection attempt is passed and the NAT occurs and it is sent out the inside interface. If you don't see the response (TCP SYN-ACK) from 192.168.5.2 then look downstream for the reason it is not working.
(I see you have fixed it but leaving this here because it would be the proper next step in troubleshooting.)
-
Yeah this was never pfsense, if you see the traffic sent on the pfsense lan side via a sniff. Pfsense did exactly what you told it too do.. See packet on wan, forward it to xyz on port abc.. If there is no answer that has nothing to do with pfsense.
To be honest in the like 12 years I have been here, I don't actually recall ever a port forwarding question that was ever an issue with pfsense..