Static IP WAN block, devices not connecting
-
It's almost certainly because there is no outbound NAT happening. And that is probably because the WAN interface doesn't have the gateway set on it directly.
In the outbound NAT rules page do you see the auto generated rules for 192.168.10.0/24 on WAN?Steve
-
@stephenw10 said in Static IP WAN block, devices not connecting:
It's almost certainly because there is no outbound NAT happening. And that is probably because the WAN interface doesn't have the gateway set on it directly.
In the outbound NAT rules page do you see the auto generated rules for 192.168.10.0/24 on WAN?Steve
Thanks, Steve, yes I do.
Could you explain what you mean by "doesn't have the gateway set on it directly"? I have the upstream IPv4 gateway set for 70.x.x.14 in the WAN interface on pfSense, and the gateway itself has its "Public Gateway Address" set for 70.x.x.14 in its "Public Subnet" section of the Subnets & DHCP GUI.
I'm back at the point of power cycling. I appreciate everyone's help.
-
Just to be thorough:
- The pfSense router can communicate with the world
- The LAN devices can communicate among themselves (and across VLANs) and with the router
- A device connected directly to the gateway's built-in switch can communicate with both the world and the gateway GUI
- No LAN device (connected to the router's LAN port through a switch) can communicate with the world or the gateway GUI
-
@tcw
In this case you have to assign an IP to pfSense WAN in the 192.168.1.0/24 subnet.
Firewall > Virtual IPs. Add an IP of type "IP alias" to WAN, maybe 192.168.1.2, set the correct mask.Then add an outbound NAT rule to WAN to the top of the rule set for the source of all your internal subnet (e.g. 192.168.0.0/16), destination = network 192.168.1.254/32, translation = the virtual IP you've added before.
-
@tcw So I might use the PCap feature here to see whats going out the WAN interface. If you ping (internal) ---> (4.2.2.2), when that comes out the WAN interface what is the source address then? If it's not 70.x.x.13 you have a NAT issue. What is the return traffic look like if there is any.
As an aside:
I have AT&T fiber and other than mine being DHCP with pass-through it's just like what you have. I can access my AT&T network box without any virtual IP or extra NAT setup. I'd start with why you can't get to internet hosts first and tackle the GUI on their gear after that is sorted.Here's the result when I ping from and internal client to that address:
15:03:43.879742 IP (tos 0x0, ttl 62, id 7358, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->e8b8)!)
104.X.X.253 > 4.2.2.2: ICMP echo request, id 17514, seq 22, length 64
15:03:43.891511 IP (tos 0x0, ttl 55, id 14527, offset 0, flags [none], proto ICMP (1), length 84)
4.2.2.2 > 104.x.x253: ICMP echo reply, id 17514, seq 22, length 64Here is the same to 192.168.1.254:
15:06:12.813810 IP (tos 0x0, ttl 62, id 37941, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->b49e)!)
104.x.x.253 > 192.168.1.254: ICMP echo request, id 34505, seq 18, length 64
15:06:12.814471 IP (tos 0x0, ttl 64, id 59990, offset 0, flags [none], proto ICMP (1), length 84)
192.168.1.254 > 104.x.x.253: ICMP echo reply, id 34505, seq 18, length 64It "just works" as long as my other internet bound NAT is working.
-
Solved. The LAN interfaces' IPv6 configuration was still set to Track Interface (instead of Disabled). I disabled DHCP6 on the WAN interface before I started, but I didn't go back to the LAN interfaces to disable stateless DHCP and IPv6. It was not enough to disable IPv6 on the WAN side even though there was no WAN IPv6 interface to track.
I did find a flaky cable in the process, and I learned a lot about outbound NAT. Thanks all for walking me through everything!
-
@tcw said in Static IP WAN block, devices not connecting:
The LAN interfaces' IPv6 configuration was still set to Track Interface (instead of Disabled).
Strange that this matters even when connecting to an IPv4.
-
@viragomann said in Static IP WAN block, devices not connecting:
Strange that this matters even when connecting to an IPv4.
Indeed... was not even thinking of v6 config.
-
Running 22.05 bare metal on an E300-8D for sake of completeness for anyone coming back to this thread. If this is a bug (or even just undesired behavior for an edge case that the GUI should prevent or throw a warning for) I'm happy to provide any additional information.
-
Well it caused me to go ahead and clean up the v6 configuration on mine. I was not having this issue but I did have some things running that likely did not need to be as well as the outside and inside picking up v6 addresses. May as well keep it simple.