WAN link shows UP but no internet after replacing ISP modem with DHCP-bridge

Environment

Home network: pfSense 2.6.0 on an x86 appliance as edge router, ISP provided modem replaced with a new modem configured in DHCP-bridge mode, single /24 upstream, clients on internal 192.168.1.0/24 network, NAT enabled on pfSense.

Symptoms

After swapping in the new modem (set to bridge), pfSense reports WAN interface link up and has an IP from the ISP, but internal clients cannot reach internet (DNS and HTTP time out). The router's web UI can ping the ISP gateway but traceroute from pfSense to 8.8.8.8 times out after the first hop.

Observations

pfSense WAN shows received public IP and correct gateway; ARP table contains the ISP gateway and modem MAC. DHCP lease list populated. Packet capture on pfSense WAN shows outbound TCP SYNs with no replies; ICMP echo from pfSense to 8.8.8.8 is not answered. Upstream modem logs show DHCP relay but no NAT entries. Internal client gets DNS via pfSense but DNS queries to public resolvers time out. No firewall rules changed during swap.

Already attempted

Rebooted modem and pfSense; swapped WAN cable to different port; disabled and re-enabled WAN interface; performed packet capture on WAN and LAN; changed pfSense default gateway to the modem IP and back; tested with another laptop directly connected to modem in bridge (it received public IP and could access internet).

Question

What are likely causes for pfSense to have a valid public IP but fail to reach internet only after replacing the modem with a bridged modem, and what safe diagnostics and mitigations should I run without disrupting production clients?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Modem bridge implements Carrier-Grade NAT or a double-NAT when in supposed bridge mode, causing asymmetric routing back to pfSense. 50%

ISP requires the modem to present the same MAC or persistent DHCP identifier; new modem/bridge got a different MAC and ISP blocks some traffic. 40%

ARP table/gateway MAC mismatch: modem's MAC to the ISP differs from assumed gateway, causing pfSense to send to the wrong next hop if static ARP or stale cache present on ISP side or device chain in front of pfSense (switch). 20%

Summary

Symptoms point to asymmetric path or upstream blocking of outbound packets despite a valid DHCP lease. Because a laptop directly on the modem can access the internet, the modem bridge appears functional. The router obtains an IP but outbound packets are not forwarded or responses are not reaching the router — common causes include MTU/MSS issues, ARP/gateway MAC confusion when modem bridging changes next-hop MACs, ISP binding the public IP to a specific MAC, or modem operating in a partial-bridge (carrier-grade NAT still active). Misconfigured firewall or floating rule on pfSense triggered by upstream changes is also possible.

Suggested Fixes

Diagnostic step 1

Connect a spare laptop to the modem in bridge mode and run the same ping/traceroute tests you ran from pfSense to confirm modem bridging consistency (you already did this; note MTU and path MTU behaviour with ping -s and -M do).

Diagnostic step 2

From pfSense, run packet capture (WAN) while initiating a simple TCP/ICMP test and check whether responses arrive at the interface; compare source/destination MACs and IPs to confirm return path reaches pfSense's MAC.

Diagnostic step 3

Temporarily set pfSense WAN to use the modem's MAC address (clone WAN MAC) to rule out ISP MAC binding.