How can I tell my pfsense box a route to my upstream gateway?
-
Dude. ARP does not cross router ports. ARP is a broadcast protocol. Routers don't forward broadcasts. WTF are you trying to do? Stop overthinking it.
Routing List
Destination IP Subnet Mask Gateway Interface Metric Route Mode Type
192.168.102.0 255.255.255.0 192.168.103.1 LAN 5 Transport Manual
192.168.102.22 255.255.255.255 192.168.102.1 LAN 3 Transport Manual
192.168.103.1 255.255.255.255 192.168.102.1 LAN 5 Transport ManualHow do you expect to get to the 192.168.102.1 AND 192.168.103.1 over the LAN interface?
-
Dude. ARP does not cross router ports. ARP is a broadcast protocol. Routers don't forward broadcasts. WTF are you trying to do? Stop overthinking it.
Thanks, but Steve already pointed that out.
Routing List
Destination IP Subnet Mask Gateway Interface Metric Route Mode Type
192.168.102.0 255.255.255.0 192.168.103.1 LAN 5 Transport Manual
192.168.102.22 255.255.255.255 192.168.102.1 LAN 3 Transport Manual
192.168.103.1 255.255.255.255 192.168.102.1 LAN 5 Transport ManualHow do you expect to get to the 192.168.102.1 AND 192.168.103.1 over the LAN interface?
I put full details in my original post - including how I already HAD an always pass any to any from any rule - as well as having disable packet filtering entirely via the System/Advanced/Fw/nat checkbox. I always put in the upstream router rules and how they corrected the actual routing issues as I see them.
In the most recent reinstall test I moved the pfsense WAN side to 103.1 from 101.3, in case the upstream 101.1 gateway was interfering in some fashion. That third entry, as I pointed out, was added as I grasp at straws.
Again, if I put it in bridge mode, then it does work, so that's the behavior I'd like to focus on.
-
There is no need to grasp at straws. You need to un-fuck your network and you apparently need help to do so. Draw a diagram of what you're trying to do complete with interface IP addresses and netmasks.
-
There is no need to grasp at straws. You need to un-fuck your network and you apparently need help to do so. Draw a diagram of what you're trying to do complete with interface IP addresses and netmasks.
Here's a fresh install, new IPs, same issues.
[PC1]–[UpstreamRouter]
I
[PFsenseDMZ]
[PC2]–[PFsenseLAN1]UR:UpstreamRouter 10.10.10.1 255.255.255.0 (static)
PC1 on DMZ 10.10.10.20 255.255.255.0 (dhcp via UR gw 10.10.10.1)PFsenseDMZ 192.168.1.1 255.255.255.0 UpGW 10.10.10.1
PFsenseLAN1 192.168.2.1 255.255.255.0 No GW
PC2 on LAN2 192.168.2.2 255.255.255.0 (dhcp via pfsense gw 192.168.2.1)In bridge mode, everyone can ping everyone else.
Unbridged, PC2 can ping only to pfWAN, not PC1 or UR and PC1 can ping to UR but not PC2 or ANY PF Nic.PFSense has a floating, quick "Apply the action immediately on match.", allow any from any to any rule applied. The "Disable all packet filtering" checkbox is also checked and NAT is set to manaual with all rules disabled. There are no blocking rules in place - at least none visible via the GUI. The bogon and RFC network non-exclusions are checked.
There are no pfsense routes in the gui. The ones I assume are automatic don't appear to work unbridged and if I try to manual add them it complains of IP conflict vs the IP GW. I'd be glad to input a route there if someone can provide the complete IP data (w.x.y.z and subnet slash value that SHOULD work).
I'm also glad to run any command lines and post that. To repeat the obvious, bridging DMZ-LAN lets ping and arp work. Unbridged, arp works but ping does not.
Again, bridged, it works. Unbridged it does not. This seems like a key detail to me. I'd also welcome an explanation that explains BOTH why that fixes it and simultaneously explains why the automatic routes don't.
Interface, Gateway and FWRules screenshots follow.
-
Why the hell are you messing around with FLOATING RULES!?!
That's not in any walkthrough I know of.
STOP OVERTHINKING IT and put your pass rule on LAN.
That's not a diagram. Draw one in crayon and take a picture if you have to.
-
Why the hell are you messing around with FLOATING RULES!?!
That's not in any walkthrough I know of.
STOP OVERTHINKING IT and put your pass rule on LAN.
That's not a diagram. Draw one in crayon and take a picture if you have to.
The floating rule was to eliminate the other tabs as concerns.
In any case, I do have pass any any on both wan/dmz and lan. See attached.
-
Your diagram has pfSense with DMZ and LAN interfaces, and no interface IP addresses, yet your screenshot has WAN and LAN interfaces? Which is it?
Annotate your diagram with IP addresses and subnet masks of the various interfaces and make it as matchymatchy with what your screenshots say as possible so people know what they heck you're trying to do.
-
When you've bridged the LAN and WAN and you have completely open firewall rules your downstream clients are effectively talking directly to your upstream router. That clearly removes whatever arp issue is causing problems.
Steve
-
When you've bridged the LAN and WAN and you have completely open firewall rules your downstream clients are effectively talking directly to your upstream router. That clearly removes whatever arp issue is causing problems.
Steve
My thought exactly, Steve. I just don't know what else to try on the pfsense box to resolve that. It's as if it is ignoring the default gateway or has some other hidden automatic route somehow or there is a hidden filter still being applied (despite the disable packet filtering being checked). Any thoughts on how I can diagnose that diagnose that?
Your diagram has pfSense with DMZ and LAN interfaces, and no interface IP addresses, yet your screenshot has WAN and LAN interfaces? Which is it?
Annotate your diagram with IP addresses and subnet masks of the various interfaces and make it as matchymatchy with what your screenshots say as possible so people know what they heck you're trying to do.
Here's a new diagram with the IPs on the diagram itself rather than in the comment.
I haven't renamed interfaces from the default for the GUI. The "WAN" from the pfsense screenshots is the DMZ.
Green lines are working links. The red line is a link that works only in bridged mode and the yellow line within the pfsense box is where I suspect there is an issue.
-
You have the pfSenseDMZ interface set with an interface address of 192.168.1.1/24. You are expecting it to be able to send traffic to 10.10.10.1. You can't do that. The gateway for an interface MUST be on the same subnet/segment as the interface itself.
This is basic IP routing / subnetting.
-
You have the pfSenseDMZ interface set with an interface address of 192.168.1.1/24. You are expecting it to be able to send traffic to 10.10.10.1. You can't do that. The gateway for an interface MUST be on the same subnet/segment as the interface itself.
This is basic IP routing / subnetting.
Actually it's a typo in the pic since I've wiped and reset it a number of times. The pfsense DMZ side IP is 10.10.10.2
Corrected pic attached.
-
So what's not working?
What is it you want to have happen? Be specific and let's work one thing at a time.
-
So what's not working?
What is it you want to have happen? Be specific and let's work one thing at a time.
For starters, I want PC1 1.10.10.20 to be able to ping the DMZ/WAN IP 10.10.10.2 on the pfsense box when it is NOT in bridged mode. If it is bridged, I can ping it. If not I can't. Bridged, or not, I can ARP from either side.
-
Start from scratch on pfSense. Enable your WAN (DMZ) interface as 10.10.10.2/24. Create a gateway of 10.10.10.1. Uncheck block private networks.
Set your LAN interface to 192.168.2.2/24.
Edit your firewall rules on WAN/DMZ. Add a pass rule for IPv4 ICMP any Source any Dest WAN address.
DON'T DO ANYTHING ELSE! 10.10.10.1 and 10.10.10.20 will be able to ping 10.10.10.2.
See screen shot. You won't have the block private rule….
 -
Done and done.
At first I could only ping the LAN side. I had DHCP setup as well and despite giving LAN a .2 address, it was handing out .1 as the GW. I tried putting in .2 as the dhcp server gw, ipconfig/renew'ed and I STILL got .1 as a GW. I switched to static with .3 for PC2 on the LAN and .2 as it's GW, I could then ping both LAN and DMZ side.
I can NOT ping the upstream GW at 10.10.10.1.
(PC1, on DMZ 10.10.10.20) can NOT ping 10.10.10.2 either.)So DHCP oddity aside, the same behavior I've seen in every test to date on this system.
-
Why are you making this so goddamn complicated? Why are you trying to ping the LAN side? Did you REALLY wipe pfSense and start from scratch?
This was to test ONE thing. Pinging 10.10.10.2 from 10.10.10.1 and 10.10.10.20. Can you now do that or not?
There are some problems with the way you are trying to do this which we will get to later if you just follow along, step by step, and not get all clicky clicky.
-
Why are you making this so goddamn complicated? Why are you trying to ping the LAN side? Did you REALLY wipe pfSense and start from scratch?
This was to test ONE thing. Pinging 10.10.10.2 from 10.10.10.1 and 10.10.10.20. Can you now do that or not?
There are some problems with the way you are trying to do this which we will get to later if you just follow along, step by step, and not get all clicky clicky.
Pinging 10.10.10.2 from 10.10.10.1: Failure.
Pinging 10.10.10.2 from 10.10.10.20: Failure. -
Then your hardware is a complete fail or you're not doing what I'm saying to do.
-
And yet it works in bridged mode, that's why I don't understand - if it was a HW issue that shouldn't have worked either. I feel like I need to take a lead pencil and bridge a wire somewhere, like overclocking an old Athlon. I'll try the nightly build during the week and see if that resolves it for chuckles.
-
Which brings us back to you not doing what I'm saying to do.
Look. You are putting three interfaces on a LAN segment:
10.10.10.1/24
10.10.10.2/24
10.10.10.20/24You MUST tell the FIREWALL interface on 10.10.10.2 to PASS ICMP traffic inbound to it's own address or you won't be able to ping it.
You MUST tell the firewall not to block private traffic which is a default setting for this software.It's that simple. If it's not working then something else on your network is hosed.
There is nothing wrong with pfSense. You can spin your wheels trying different builds but it's not going to help. If you would STOP thinking something is wrong with pfSense and START looking at what's wrong with your network, you might have a prayer of fixing it.
