WAN NAT working except when accessing from LAN subnet
-
Hello
I think that this is distinct from a 2014 example where attempted to go to a WAN NAT 1:1 address was instead bringing up the Netgate GUI login, but could be wrong. Apologies if we missed something there.
We have just migrated a second Netscreen firewall to a Netgate device. The former migration has been up and running for about 6 months without issue including for NAT 1:1 which it has a lot of. That firewall does use routed IP addresses whereas the latest firewall requires ARP.
The NAT addresses are all within the same subnet as the WAN address e.g.
WAN 2.2.2.1/26
NAT 2.2.2.8/32 -> 192.168.0.8 (LAN)
NAT 2.2.2.2/32 -> 10.0.0.2 (DMZ)
Virtual IP configured for 2.2.2.2 and 2.2.2.8 (and Proxy IP tried too)
LAN 192.168.0.1/24From any device on the WAN the NAT and rules work perfectly e.g. 2.2.2.72:80 brings up a webpage. Similarly for the NAT to the LAN.
However, from the LAN 2.2.2.2:80 times out. Ditto 2.2.2.8:80. Doing a packet trace the packets can be see to arrive at the Netgate on the LAN interface but not on the WAN. Similarly Wireshark shows packets leaving the client but none being received by either NAT'd server.
Can anyone suggest what else we should test.
The GUI is set to https on a different port from 443. Changing the WebGUI Redirect appears to make no difference.
As mentioned above we have tried both IP Aliases and Proxy ARP but the results have been the same. There was nothing obvious in /tmp/rules.debug although we did notice that the WAN interface had both its own IP/subnet and the NAT'd addresses listed. We haven't tried changing the WAN interface address to 2.2.2.1/31 (or similar) instead, as we don't wish to break working connections which may be in use.
WAN = "{ ix3 }"
table <WAN__NETWORK> persist { 2.2.2.1/26 2.2.2.2/32 2.2.2.8/32 }
WAN__NETWORK = "<WAN__NETWORK>"
LAN = "{ igc0 }"
table <LAN__NETWORK> persist { 192.168.1.0/24 }
LAN__NETWORK = "<LAN__NETWORK>"
DMZ = "{ igc1 }"
table <OPT4__NETWORK> persist { 10.0.0.0/24 }
OPT4__NETWORK = "<OPT4__NETWORK>"
GUEST = "{ igc2 }"
table <OPT5__NETWORK> persist { 192.168.254.0/24 }
OPT5__NETWORK = "<OPT5__NETWORK>"
IPsec = "{ enc0 }"Does anyone have any suggestions of other tests we should try to indentify and fix this please?
David
-
@DavidS8 said in WAN NAT working except when accessing from LAN subnet:
However, from the LAN 2.2.2.2:80 times out. Ditto 2.2.2.8:80. Doing a packet trace the packets can be see to arrive at the Netgate on the LAN interface but not on the WAN. Similarly Wireshark shows packets leaving the client but none being received by either NAT'd server.
This needs NAT reflection to be enabled.
However, if you use host names to access your servers I'd rather suggest to configure host overrides on your internal DNS.
-
@viragomann Thank you, that appears to be spot on as we have it enabled system-wide on the other firewall and had assumed that it was that way as the default.
Our internal DNS is Windows which, as far as we have discovered, demands that you create a zone for each primary domain for which you want to have a subdomain entry. That we recall, bind doesn't impose that requirement. Editing the local route table for each workstation would be an option too, but not ideal.
What problems with enabling the reflection are suggesting we would avoid with using a different method?
Thanks again
David
-
@DavidS8
With NAT reflection, the router does masquerading, which is necessary to avoid asymmetric routing issues.This means, on the destination server you will see the access coming from the routers interface IP instead of the original clients IP.
-
@viragomann I was thinking that was like the Netscreen devices and didn't think it would matter for us as a small company. We don't need to apply website access rules according to local IP either.
That said, having just checked the Apache logs for one website it is showing the correct client IP for both LAN-based and WAN-based browsers.
Thanks again,
David