Traffic goes where ?
-
Some traffic from LAN to SERVER does not go through as expected.
The set up:
LAN rules:
Server rules:
From the client on the LAN i can ping both NAS and Proxmox.
I can connect to the proxmox server on port 8006 without issues.But i cant connect to the NAS on port 443.
I know that port 443 is open and answering on the NAS, since if i directly connect the PC to the NAS i get acceess.
But it feels like the response traffic for some reason doesn't go back to the PC when connected to pfSense.What am i missing ?
-
@LB-0
I guess, there is a firewall on the NAS, which blocks access from outside of its subnet. -
No Firewall active on the NAS.
-
@LB-0 I'd have to assume it has something to do with that WG gateway rule but since you can ping from the .10, that seems unlikely.
Just to test disable that rule on the server interface and enable the rule above it.
Does it work then? -
@Jarhead No change when enableing that rule and there should not be a need for any rule on the SERVER nic since the traffic originates from the LAN and pfsense is a stetefull FW.
The WG (wiregard) gateway is a rule to tunnel all traffic NOT going to private network via it.
The private_network alias contains the LAN subnet as well.Ive been trying to figure out how i can see what path the traffic takes through the pfSense. Cisco has a good feature called packet trace that can simulate a packet and show you all steps the FW does with it.
-
@LB-0
So it's time to sniff the traffic on the pfSense interface, which faces to the NAS, while you try to access it.
What do you see there?
If there is nothing take a capture on LAN. -
@LB-0 said in Traffic goes where ?:
@Jarhead No change when enableing that rule and there should not be a need for any rule on the SERVER nic since the traffic originates from the LAN and pfsense is a stetefull FW.
Very true but if the return traffic was going out the WG tunnel, there would be your problem. By disabling that rule you should have gotten rid of the tunnel path and you would need the rule above it to make sure that subnet still had access to anything while testing.
As Viragomann said, start sniffing. I'm still betting the return traffic is hitting the WG tunnel. You can sniff on it and see if the packets are forced that way.