WAN connectivity failing despite allow rules, and creating no log entries

[CyberMinion]

Hi, I'm probably doing something stupid again, but I can't get WAN connectivity working for a new interface, even though I have a very broad allow rule in place. Oddly, there are no relevant log entries.

The first two (LAN) rules are working fine.

The third rule shows a small amount of traffic, but all connection attempts I make, time out.
The last (reject) rule is technically not needed, but in any case, shows no hits.

Yet ICMP, HTTP/S, SSH, etc. outbound connections to the WAN all time out. Such connections within the LAN, including on separate interfaces, all work fine. Despite all of these failed connections, the logs show nothing of interest for this interface (the timestamp indicates this is old news anyway)

And nothing at all for the test device on this interface, in or out.

I have Snort, but it has not blocked anything. I have pfBlockerNG, but it is currently disabled. I've checked the Float and WAN rules, and they appear to have nothing relevant. I have other interfaces, connecting through the default gateway and out to the WAN, just fine.

Here is the config for this interface, in case that matters:

Any idea what I'm missing? I assume I've done (or not done) something stupid again.

[patient0]

@CyberMinion ping the pfSense OPT6 address, 192.168.11.1 does work and so do the queries to the DNS queries to 192.168.10.10, yes? And do they show up in the packet capture?

• can you SSH into pfSense from OPT6?
• how is WAN and OPT6 configured (static, dynamic, VLAN)?
• from what client did you connect, does DHCP work clients on OPT6?
• on what pfSense version are you?

And as you said the third rule is getting some traffic with 36 open states (you can click on it), you have to be able to capture it, and/or enable logging on the firewall rule.

[CyberMinion]

@patient0 said in WAN connectivity failing despite allow rules, and creating no log entries:

@CyberMinion ping the pfSense OPT6 address, 192.168.11.1 does work and so do the queries to the DNS queries to 192.168.10.10, yes? And do they show up in the packet capture?

• can you SSH into pfSense from OPT6?
• how is WAN and OPT6 configured (static, dynamic, VLAN)?
• from what client did you connect, does DHCP work clients on OPT6?
• on what pfSense version are you?

And as you said the third rule is getting some traffic with 36 open states (you can click on it), you have to be able to capture it, and/or enable logging on the firewall rule.

Yes, pinging the OPT6 address of 192.168.11.1 works, and I can access the admin console via browser as well. DNS queries are going through to 192.168.10.10, and responses are being delivered. All good there. I did not run a packet capture, as I had forgotten that was a built-in feature. I'll give that a try.

-SSH is disabled on the pfSense currently, so that wouldn't work under any condition. Since port 80 and ICMP work, I assume it would.
-WAN is DHCP, Opt6 is set as static (but with the DHCP server enabled for the interface, with its subnet).
-I connected a workstation directly to opt6, and yes, it got a DHCP address after some troubleshooting due to misconfiguration. DHCP is now working on this interface, as evidenced by the valid assignment I received.
-I'm on pfSense version 2.7.2. I have not yet upgraded to the new stable release.

Clicking on that number, told me "no states found." I located the checkbox for logging, and will try enabling that.

[SteveITS]

@CyberMinion Try a traceroute to 8.8.4.4 or something out the WAN.

Does anything on the WAN side of pfSense use the same subnet as OPT6?

[CyberMinion]

@SteveITS No, 192.168.11.x is free, there should be no conflicts. Good thought though.

[CyberMinion]

Okay, I'm even more confused now. I changed IP range , just in case there's a zombie policy somewhere. (firewall is now 192.168.18.1, client in this case is 192.168.18.5. I'm now seeing states on the firewall, for this interface. I also enabled logging, and ran a packet capture.

The firewall log shows regular traffic being allowed, based on the generous allow policy I have.

The packet capture shows a whole bunch of TCP retransmits, and unanswered SYNs.

I tried a traceroute was suggested, and got timeouts after the firewall.

Lastly, a possible puzzle piece: I found an active but unused gateway, listing opt6 as the interface(!!). I tried disabling then deleting that gateway, but doing so did not seemingly affect the symptoms I'm seeing.