Need help with pfsense routing problem
pfsense 2.4.0-BETA (arm)
built on Mon Aug 14 08:04:55 CDT 2017
I have pfsense router, Win7 PC configured as a router with 2 LANs and a Device connected as follows:
Internet –- WAN pfsense LAN 10.0.0.1 --- 10.0.0.100 LAN1 Win7 LAN2 10.0.1.100 --- 10.0.1.101 LAN Device
All devices have netmask 255.255.255.0
System->Routing->Static route on pfsense:
10.0.1.0/24 to 10.0.0.100
Win7 PC can browse and ping internet and other devices on 10.0.0.x, same for 10.0.1.x, including Device
Device cannot reach the internet. DNS requests to 10.0.0.1 or 184.108.40.206 reach the pfsense router but are not replied to.
Device pings, browser requests, NTP requests reach pfsense but get no replies.
Running the pfsense Packet Capture on pfsense LAN shows the ping, browser, NTP, etc packets from Device going outbound but no replies.
How do I configure pfsense to return the reply packets whose requests are originated by Device?
I have the static route but obviously something else is needed.
Firewall rule on pfSense LAN that passes traffic sourced from 10.0.1.0/24 in addition to 10.0.0.0/24 (LAN net) ??
Thanks Derelict for the reply!
there are only 2 LAN rules from Firewall->Rules->LAN
one is the antilockout rule auto created by pfsense
another is the LAN to any rule... see the image please.
I thought this would handle the wide open rule for all the LAN replies. I think was also automatically created by pfsense.
Am I missing yet another rule?
![pfsense fw lan rules Screenshot from 2017-08-19 03:09:57.png](/public/imported_attachments/1/pfsense fw lan rules Screenshot from 2017-08-19 03:09:57.png)
![pfsense fw lan rules Screenshot from 2017-08-19 03:09:57.png_thumb](/public/imported_attachments/1/pfsense fw lan rules Screenshot from 2017-08-19 03:09:57.png_thumb)
Yes you are missing a rule. LAN net is the LAN interface's subnet, or 10.0.0.0/24. That will not match traffic into LAN sourced from outside that subnet such as 10.0.1.0/24.
Duplicate that rule substituting network 10.0.1.0/24 for LAN net and it will probably work.
Is this how it should look?
How does this allow the response packets in from the wan to lan?
I guess my confusion was that I originally configured "all LAN traffic" as accept (I dont think I wrote a rule but there was some higher level pfsense way to do it). It appeared to me the the response was getting stopped. Are you saying that the 10.0.1.x packets coming in to the pfsesne LAN from my inside net were getting dropped and never actually sent out the pfsense WAN? (AND thus it was not the responses suposedly returning from the internet to the WAN getting stopped?)
It appears to work for the NTP according to the pfsense Packet Capture for UDP as a quick test! I will have to test other protos but it seems right now!
![pfsense fw extra lan rule Screenshot from 2017-08-19 09:04:15.png](/public/imported_attachments/1/pfsense fw extra lan rule Screenshot from 2017-08-19 09:04:15.png)
![pfsense fw extra lan rule Screenshot from 2017-08-19 09:04:15.png_thumb](/public/imported_attachments/1/pfsense fw extra lan rule Screenshot from 2017-08-19 09:04:15.png_thumb)
"How does this allow the response packets in from the wan to lan?"
Because of STATES ;)
And just because it comes up all the time.. wan is not the internet.. Wan is just the net that interface is connected to..
"Win7 LAN2 10.0.1.100 –- 10.0.1.101 LAN Device"
So your using this win7 downstream router or NAT device. I would guess your using say internet sharing on this win7 PC so it nats any traffic from the 10.0.1 as its 10.0.0.100 IP... So pfsense would never see any traffic from this 10.0.1 network.. Doesn't give 2 shits about it.. No rules would need to include this network since pfsense would never see it..
Only if you were going to be using this win7 pc as a downstream router would pfsense ever have to know (routes) or have rules about that network.. As long as the win7 pc is going to nat that network behind it pfsense becomes oblivious to it.
Being new to pfsense I misunderstood thinking these rules were interface based.
I'm not using win7 "internet connection sharing" because it is too limiting and implacable. When that is used several things come into play:
1. It is configured on an interface basis. One has to configure it for each interface desired. Not an issue but just a fact. ICS is mostly magic and extremely poorly documented on how it works (because it is a kludge).
2. It FORCES the interface to be a 192.168 network. The user has no choice and as far as I could learn it is not changeable even with the registry.
So, no, I'm not using ICS. Rather, I'm simply using win7 as a router between 10.0.1.x and 10.0.0.x. It forwards packets between them. I'm using win7 because this is a server running win-only software to support primarily many cameras on the 10.0.1.x subnet and is isolated for bandwidth consumption. It takes just a couple of win7 settings to make this work as a simple subnet-to-subnet router.
These cameras only need NTP and for convenience occasional access from the web for configuration (I dont even have them requesting DNS). The win7 software serves up the operational access. Normally internet access is not needed directly to the cameras on 10.0.1.x.
Thanks for the additional insight. I'm still learning pfsense.
Yes, that is what you need.
Note that if you are trying to segment those cameras, it is up to the Win7 router to filter what the cameras can and cannot access on the pfSense LAN segment. pfSense is not involved in communications between 10.0.1.0/24 and 10.0.0.0/24.
You will have a pretty hosed asymmetric routing problem there that might help keep reply traffic from making it back though.
I would, personally, use another interface on the firewall for that. If you need the windows PC on that segment, put it there.