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?
-
I think it's a DNS issue that seems to resolve but then it gives a time out
I changed the ISP's DNS and disabled the "DNS Server Override" option so that it only uses the DNS that I have established, which are 8.8.8.8 and 8.8.4.4
And it doesn't do nslookup even from the WAN interface
-
@HidekiSenpai what does it show in your dns lookup diag..
-
@johnpoz I disabled IPv6 entirely, in case there was a conflict, and after doing so, it started resolving queries with external DNS, but the response is not authoritative.
And then if I make a normal query, it's using 8.8.8.8, it doesn't recognize the server, and I get this:
But if I make a direct query to 192.168.2.1 (which is the pfSense LAN), it recognizes the server but gives an error:
Here are my unbound settings:
-
@HidekiSenpai not sure why you think a query to quad9 would be authoritative.. quad9 is not the authoritative ns for google.com
Your unbound setting there are resolver mode, for you to be able to resolve you would have to be able to talk to all the NS on port 53.. If your upstream is blocking this then yeah your going to have issues.
What does dns lookup on the diagnostic menu dns lookup report?
To test if you can resolve and to see where you might be having issues do a dig + trace on pfsense.
[25.07.1-RELEASE][admin@sg4860.home.arpa]/root: dig google.com +trace ; <<>> DiG 9.20.6 <<>> google.com +trace ;; global options: +cmd . 84617 IN NS d.root-servers.net. . 84617 IN NS f.root-servers.net. . 84617 IN NS e.root-servers.net. . 84617 IN NS m.root-servers.net. . 84617 IN NS j.root-servers.net. . 84617 IN NS b.root-servers.net. . 84617 IN NS c.root-servers.net. . 84617 IN NS g.root-servers.net. . 84617 IN NS k.root-servers.net. . 84617 IN NS l.root-servers.net. . 84617 IN NS a.root-servers.net. . 84617 IN NS h.root-servers.net. . 84617 IN NS i.root-servers.net. . 84617 IN RRSIG NS 8 0 518400 20250915050000 20250902040000 46441 . r2EKEjvLOSDMWT4XAMJK+3McQntRgJ/wtG2WXCZ90DdKxUgNUCU1Q1R+ YDovtNQExt87dM1gu8S10al5FJPNkLM6pbQM010+1E2AnyCQyt4DQrJh JgMhwcYONIbT/gGrXfQS7sdN8B5g0ob2HcqXRxqMkDOldxdBCJy7B5ZM AufoQlrCrdazkGHVxC+vzsDIDVYnAFLlLkoHtcpbLmiK1w6MiVNfzfWt EC4v7Bibau5rMYzhYZ0EwGv4CCG6dn8HiGEg0rNBmMi7onXndKhq2S4H T9b1jkIj1qG1GfVOzVuqmzv7OWgW9+0jbqel3VR7AAfO9plH7JLeVNY1 EmTLTg== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A com. 86400 IN RRSIG DS 8 1 86400 20250915050000 20250902040000 46441 . PuEt7PPZTytXpON7kI4PR4ePmn1RbbZwWwksIwQqStFADSXkHLtaCWBk 6rjtDQogfGqqcRZnJzXTwq7FD+lsB//y3DBBkzBB+ag7XmldiFGtkV3Y 9ueUEL4ydZnyftPClzOtBYbtzMVA2oC6gfNbi7LyIFUUH8xc0IZUPJah 9IQF443ZocHNNl8jPpSilA7QVkSf6rKRH5CNUdTsJ6qhfXUEOWgNqIaV yLCrPzsnyl7+PoU1dBpPmsbUY0DUO2A0E5Zs5lBpcgjThoEK/SMokB1v Rb75/7Yvb+MGyDWmZVwd9uKdVadxzn6jdJgxgSM+SBuxaSpkWlnqhJnx fYnP/w== ;; Received 1170 bytes from 2001:503:c27::2:30#53(j.root-servers.net) in 9 ms google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 20250908002603 20250831231603 20545 com. I5bq7mPPNzfXbaaD27hOUwaUOIQJi6EcJYwN+Ab4FiMqp5GgoHWsfgSm LHUn2Mg3jXAGfxykTCnJXfUQYtJ+oQ== S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 900 IN NSEC3 1 1 0 - S84BR9CIB2A20L3ETR1M2415ENPP99L8 NS DS RRSIG S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 900 IN RRSIG NSEC3 13 2 900 20250909012623 20250902001623 20545 com. 1Sn2h2Xvf9GUFWqqEDwCOD+aZFVhrEhV+87H/RxeCGuNoA42E7tz5Oq6 A7hnIkd0J8coWN0C9M9gQlJLjrrfvw== ;; Received 644 bytes from 192.26.92.30#53(c.gtld-servers.net) in 27 ms google.com. 300 IN A 172.217.2.46 ;; Received 55 bytes from 216.239.36.10#53(ns3.google.com) in 25 msThe dig + trace is exactly what the resolver would do - so seeing all the steps can show you were you might be failing in the process.
