HELP PLSS, Internet access issues with pfSense behind an ISP router (double NAT + VLANs on a switch)
-
Environment Description
I'm setting up a lab with pfSense behind my ISP's router. The topology is as follows:
-
ISP router: 192.168.1.1/24 (DHCP enabled).
-
pfSense WAN: DHCP client → receives 192.168.1.x from the ISP router, with gateway 192.168.1.1.
-
pfSense LAN: 192.168.2.1/24 (static).
-
TP-LINK Managed Switch with 802.1Q VLAN:
VLAN 1 (untagged): Ports 1-2-4-5
- Port 1 → ISP Router
- Port 2 → pfSense WAN
- Ports 4-5 → direct access to ISP network
VLAN 2 (untagged): Ports 3-6-7-8
- Port 3 → pfSense LAN
- Ports 6-8 → clients on pfSense network
Problem
Clients connected to the pfSense LAN (192.168.2.0/24) do not have internet access.
From Diagnostics → Ping on pfSense:
Both with WAN and LAN sources, the ping/traceroute does not reach the internet (not even 8.8.8.8 responds).
From a client on the ISP router's network (192.168.1.0/24), a ping to the pfSense WAN IP also fails.
Current Rules
Firewall → Rules → LAN: default rule "Allow LAN any → any".
Firewall → Rules → WAN:
-
Blocking of RFC1918 and bogons by default.
-
Allows HTTPS access to the firewall and IPsec rules.
-
No explicit rule for ICMP.
Firewall → Rules → Floating: one test rule "Pass any".
Firewall → NAT → Outbound: in automatic mode (rules are generated for 192.168.2.0/24 → WAN address).
System → Routing → Gateways: The WAN gateway appears online.
What I've already tried
I verified that the WAN interface is correctly receiving the IP, mask, and gateway via DHCP.
I checked the VLANs on the switch: ISP and LAN traffic from pfSense are correctly isolated on VLANs 1 and 2.
I ran ping and traceroute tests from pfSense (Diagnostics). It doesn't work with any interface (neither WAN nor LAN).
I verified that the rule on the LAN has no gateway defined (there is no policy routing).
I was able to confirm that it resolves DNS from the LAN, but no traffic is sent to the Internet.
Question / Help Requested
I'm really confused now and don't know what's going on. My suspicions:
Could blocking "private networks" on the WAN interface be preventing traffic, given that I'm using double NAT (192.168.1.0/24)?
Is it necessary to add an explicit rule on the WAN to allow ICMP responses or even all outgoing traffic?
My finality is to leave the ISP router for my parents and guests so they can stream their services without any problems, and I can have my homelab on a subnet and VLAN isolated from the ISP network.
-
-
@HidekiSenpai said in HELP PLSS, Internet access issues with pfSense behind an ISP router (double NAT + VLANs on a switch):
Could blocking "private networks" on the WAN interface be preventing traffic
That would only be source inbound traffic.. That wouldn't stop pfsense, or something behind it from going to say 8.8.8.8
Why do you have this rule?
Firewall → Rules → Floating: one test rule "Pass any".The default lan rule should be any any by default, normally there is little reason to every put anything floating. You show that your lan already has the default lan rule.
Both with WAN and LAN sources, the ping/traceroute does not reach the internet (not even 8.8.8.8 responds).
If pfsense can not ping say 8.8.8.8 then seems like you have something upstream blocking it - to your upstream router, pfsense and anything behind pfsense should just be another client on its network. If pfsense can not ping the internet from its wan IP, then it would make sense that clients could not either because pfsense would nat device on its 192.168.2 network to its wan IP 192.168.1.x
You should be able to ping stuff on the internet from pfsense wan IP, if you can not then nothing is going to work behind pfsense either because they just look like pfsense wan IP.
Pfsense can ping its gateway - ie your upstream router of pfsense, 192.168.1.x something - but it can not ping 8.8.8.8.. Do a packet capture on pfsense.. You see it send traffic to 8.8.8.8 on its wan when you ping, this is to the mac address of your upstream router on 192.168.1.x
example: here I fired up pfsense vm I have where its wan is one of pfsense interfaces 192.168.3.253, it gets its wan IP from pfsense dhcp 192.168.3.109
I can see in the arp table that mac address of its upstream router at 192.168.3.253 is my upstream pfsense interface... I then start a ping to 8.8.8.8, if I look in the packet capture I can see that it send the ping to 8.8.8.8, but if you look at what mac it sent it too - its its upstream gateway mac..
If you see that - but get no answer. Then its something upstream of pfsense causing the problem.. You say it gets a dhcp address from your upstream, and it shows its gateway online.. And you can ping that ip in pfsense diagnostic - but can not ping 8.8.8.8??
-
@johnpoz Hi, I've run the packet capture test and it's not capturing anything.
I suspect it's something between the ISP router and pfSense, because I've pinged both the WAN and LAN interfaces to the ISP router's gateway (192.168.1.1) and it arrives perfectly.
I've tried putting the pfSense WAN interface in DMZ (on the ISP router), and it's still the same.
And pings to 8.8.8.8 or any other address from the ISP network work perfectly.In conclusion: something's going on between the ISP router and pfSense, and I don't know what it could be.
Note: I have pfBlockerNG and Suricata, and I've disabled both services, but it's still the same, so I don't think it has anything to do with it.
-
@HidekiSenpai said in HELP PLSS, Internet access issues with pfSense behind an ISP router (double NAT + VLANs on a switch):
Hi, I've run the packet capture test and it's not capturing anything.
If you capture and your not seeing anything.. Then how exactly is it showing you your gateway is up? Pfsense knows its gateway is up by sending pings to the gateway..
-
@johnpoz I have been doing the pings from Diagnostics → Ping in pfSense
-
@HidekiSenpai maybe your not sniffing on the correct interface..
But pfsense shows that its gateway is online by pinging it.. So if yours shows up then clearly pfsense can talk to the gateway - unless you set it to be always online in the routing section?
But if pfsense knows the mac address of the gateway - even if it doesn't answer ping, a packet capture would show it sending pings.. Do you get some other error other than timeout?
show your arp table in pfsense. Show your routing..
This shows the default gateway.. This shows the arp table.. Even if that gateway IP didn't answer ping, if pfsense knows the mac it would send the ping and you would see it in the packet capture.. If you are not seeing it send on the ping then pfsense does not know the mac, or your sniffing on the wrong interface to where it would send it.. The routing table will show what IP pfsense has on its wan and the network, etc..
But if pfsense does not know the mac address of its gateway, and have a default gateway to to send traffic to it - then no it would never work. No matter if it answers ping or not.. If pfsense can not actually talk to its gateway then its never going to work.
maybe you have wrong mask on your lan, and this is overlapping your wan 192.168.1.0/24 network?
So lets see this info via arp table and routing table.
testing from cmd line (ssh to your pfsense) might give you bit more info as well.. So for example I try to ping an IP that doesn't exist on pfsense wan 192.168.3.0/24 network
[2.8.0-RELEASE][admin@pfSense.test.home.arpa]/root: ping 192.168.3.42 PING 192.168.3.42 (192.168.3.42): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down [2.8.0-RELEASE][admin@pfSense.test.home.arpa]/root: arp -a ? (192.168.3.42) at (incomplete) on em0 expired [ethernet]So the error is just not a timeout, but saying host is down, if then look in the arp table it was unable to find a mac for that IP.. See where it says incomplete and shows no mac address.
-
@johnpoz Here you have some attached images of how I have everything
-
@HidekiSenpai I show no gateway there, And what are those 80 address on the same interface as your wan icg0 interface.
Without a gateway no pfsense is not going to be able talk to anything other than what its connected too.. So is that 192.168.1.1 suppose to be your gateway?
Your saying you can not ping 192.168.1.74 or what I assume should be your gateway 192.168.1.1? You don't even see pfsense send the ping request??
-
@johnpoz 192.168.1.1 is my gateway 192.168.1.74 I don't know where it came from and 192.168.1.40 is the address of my igc0 WAN interface
-
@HidekiSenpai well its never going to work if you have no gateway.. but you should still be able to see a packet capture trying to ping it. Even if it doesn't answer ping.
Your saying pfsense shows your gateway is up? Lets see your gateways and add the gateway widget to your dashboard
Because from your routing table you have no gateway at all.. Only thing pfsense could talk to would be things directly connected to it.
-
Now for some reason it appears as connected and before not even that, and I haven't touched anything, the only thing I've done is add the gateways widget to the dashboard and that's it (it has nothing to do with it), what I did do a while ago is add the pfSense WAN IP to the DMZ of the ISP router, and it's possible that it has been applied now, I don't know.
Now this doesn't mean it's fixed, because it says connected but it doesn't load the pages or Discord or Spotify correctly, it's like it wants to load it but can't
-
@HidekiSenpai well what your gateways and your widget show is not what your routing table showed.. Has that changed?
You had no default route in your routing table.. And not sure where your showing that red 4 as some sort of connection.. But if your device is actually behind pfsense it sure and the hell wouldn't show that as the connection.
That name lines up with the name of those 80 IPs you showed on pfsense though
inetnum: 80.58.61.248 - 80.58.61.255 netname: RIMA descr: Red de Servicios IP country: ESSeems to me your client that says its connection is Red 4 isn't actually behind pfsense.. What does the IPconfig show on that device.. You should see pfsense 192.168.2.1 as your gateway and it should have a 192.168.2 address.
Clearly from your gateways and widget you can ping 192.168.1.1 - that is how pfsense knows its online.. But you said when you tried to ping it you got no answer and didn't even see anything on your packet capture.. Do you have some sort of vpn setup on pfsense? Maybe that is where those 80 IPs came from??
-
@johnpoz Network 4 is a Windows computer connected to pfSense, and I'm now realizing that the 80 IPs you mentioned are the default DNS settings on the ISP router.
I also tried to set up an IPsec VPN, although it didn't quite work, so I disabled it for now.
And regarding pings, from the 192.168.2.0/24 network, the ping is successful on both the WAN and LAN to the ISP router's gateway (192.168.1.1), but the packets are dropped, and nothing appears in the packet capture when I ping 8.8.8.8.
And from the 192.168.1.0/24 network, when I ping the pfSense LAN gateway (192.168.2.1), all packets are dropped, however, the ISP router detects it. to pfSense, so that's a matter for the pfSense firewall rules.What I'm thinking now is that, for the 192.168.2.0/24 network to reach the internet, does the router need to have access to pfSense? Or what?
-
@HidekiSenpai no, pfsense is just another client on your isp routers network. Your isp router wouldn't know anything about a 192.168.2 address since pfsense would nat everything to its wan IP when a 192.168.2 wanted to go to 8.8.8.8
If your not seeing a packet capture on pfsense when you ping 8.8.8.8 then that traffic isn't going through pfsense.
Lets see your routing table again - if there is no default then pinging 8.8.8.8 would never be sent to your isp router at 192.168.1.1, so no you wouldn't see it via a packet capture.
Maybe try setting your gateway in routing as default vs automatic.. But if you do not see a default route in routes then no it would never work.
-
@johnpoz I did what you told me about changing the gateway from automatic to default, and it's working for now.
It also takes a long time to load pages, Spotify takes a long time to load songs, etc.
Why could that be?
