Static IP WAN block, devices not connecting
-
@tcw said in Static IP WAN block, devices not connecting:
I can't connect to the gateway interface at 192.168.1.254 (it's a Nokia BGW320) from my browser.
So this is your internet gateway, connected to the WAN interface?
-
@tcw You need a NAT rule that NATs all your internal private IPs that will land at this firewall to the external IP of the firewall. Look at Firewall -> NAT -> Outbound. There is usually an automatic rule there to handle it. If not you might need to change the "Mode" to "Hybrid" and add a manual rule there. Source is all your internal subnets, destination is "any" and ports are "any". The NAT address is your "WAN address".
That should handle the NAT. It's odd though because if you just swapped providers I would expect there would have been NAT in place already.
-
@photomankc said in Static IP WAN block, devices not connecting:
@tcw You need a NAT rule that NATs all your internal private IPs that will land at this firewall to the external IP of the firewall. Look at Firewall -> NAT -> Outbound. There is usually an automatic rule there to handle it. If not you might need to change the "Mode" to "Hybrid" and add a manual rule there. Source is all your internal subnets, destination is "any" and ports are "any". The NAT address is your "WAN address".
That should handle the NAT. It's odd though because if you just swapped providers I would expect there would have been NAT in place already.
My apologies, you are correct and I was looking at the wrong tab. Outbound NAT is set for hybrid, with auto WAN and ISAKMP rules, and a manual static port rule for a Nintendo Switch.
-
@viragomann AT&T network box will have that address, but that IP would normally not be the default gateway for the WAN side. Just management IP of the AT&T network box. I'm on their fiber service and that's how mine works anyway. My DFGW is a public IP, but I can still get to the 192.168.1.254 management page IF the firewall is NATing the traffic going to it.
-
@tcw Okay, so we're good on WAN side, the firewall's WAN IP is getting around the world. So the issue is through the device or somehow on the LAN side.
You might try going under Diagnostics -> States -> Reset State table. That should force NAT to clear and start over. After that check the States output and see if you are getting connections built.
-
@photomankc said in Static IP WAN block, devices not connecting:
@tcw Okay, so we're good on WAN side, the firewall's WAN IP is getting around the world. So the issue is through the device or somehow on the LAN side.
You might try going under Diagnostics -> States -> Reset State table. That should force NAT to clear and start over. After that check the States output and see if you are getting connections built.
Thanks to everyone in this thread... I'm still troubleshooting. I see connections established between the pfSense public IP I assigned (70.x.x.13) and 1.1.1.1:853, but nothing from any of the internal devices. I'm seeing some "NO_TRAFFIC:SINGLE" and "CLOSED:SYN_SENT" states on the LAN with no packets/bytes, so it looks like things are trying and failing.
-
@tcw
Maybe we can get a step further if you answer my question... -
@viragomann said in Static IP WAN block, devices not connecting:
@tcw said in Static IP WAN block, devices not connecting:
I can't connect to the gateway interface at 192.168.1.254 (it's a Nokia BGW320) from my browser.
So this is your internet gateway, connected to the WAN interface?
Sorry if you were referring to this question, I did lose it in the shuffle! Yes, this is my internet gateway. It has a private IP address of 192.168.1.254 and is connected to the WAN interface of pfSense. In the pfSense GUI I have the WAN interface configured for Static IPv4, with the 70.x.x.13 address and 70.x.x.14 gateway.
-
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.
