Webserver logs shows pfsense IP instead of LAN IP
-
If im from the LAN, accesses an webserver (in this case nginx), I will see the local IP/gateway address of pfsense in the logs. I've fixed this by using splitdns, which works as intended.
However, Im sometimes required to be on VPN, where I cannot control the routing (unless I do manual local route hacks). So basically when connected to VPN, it forces access which resolves to the external IP address.
Using an tpcdump, I see that x-forwarded-for + x-real-ip are the IP of the pfsense box.
I've looked into NAT reflection and pure NAT, but the issue remains the same, but maybe im doing it wrong. https://docs.netgate.com/pfsense/en/latest/recipes/port-forwards-from-local-networks.html
-
@lbm_ said in Webserver logs shows pfsense IP instead of LAN IP:
If im from the LAN, accesses an webserver (in this case nginx), I will see the local IP/gateway address of pfsense in the logs.
Using what device from what network to which web server -- running on the same network ?
@lbm_ said in Webserver logs shows pfsense IP instead of LAN IP:
NAT reflection and pure NAT
Way to complicated.
add host overrides (bottom page Resolver settings) like :
"www.whateverdomain.tld" => 192.168.x.y (your nginx web server on your LAN)
and you'll be fine.Now you can can use "www.whateverdomain.tld" locally, no more NAT tricks needed.
-
Its from an laptop to an nginx webserver. And they are in different subnets.
Yes, im aware, but the host override is only working when the internal DNS is used. When im on VPN it pushes another DNS, and the external IP is resolved, so this is not workable.
-
@lbm_ said in Webserver logs shows pfsense IP instead of LAN IP:
When im on VPN it pushes another DNS, and the external IP is resolved
Ok - and then access to whatever this is would also go through the vpn connection, so in what scenario would you need nat reflection?
-
@lbm_ said in Webserver logs shows pfsense IP instead of LAN IP:
Its from an laptop to an nginx webserver. And they are in different subnets.
Host override still works.
@lbm_ said in Webserver logs shows pfsense IP instead of LAN IP:
When im on VPN it pushes another DNS
Why ? The resolver works fine. The resolver knows everything about locally locally connected devices, like your nginx web server. Use a MAC DHCP Static lease and have that static leases read by the Resolver :
Now you even don't need to set up a host override.
@lbm_ said in Webserver logs shows pfsense IP instead of LAN IP:
and the external IP is resolved,
?? You're using the wrong DNS resolver. Or, if possible, inform this DNS resolver who and where you web server is, with the local IP.
-
@johnpoz said in Webserver logs shows pfsense IP instead of LAN IP:
Ok - and then access to whatever this is would also go through the vpn connection, so in what scenario would you need nat reflection?
Maybe im not, but I though this would fix my issue.
@gertjan said in Webserver logs shows pfsense IP instead of LAN IP:
?? You're using the wrong DNS resolver. Or, if possible, inform this DNS resolver who and where you web server is, with the local IP.
When on VPN, an DNS is pushed/forced to be used to the client/laptop.
E.g. when not on VPN, I would resolve example.com to 192.168.10.10, but when in on VPN I would resolve it to 93.184.216.34.I might want to say, that the VPN is not in any way related to this pfsense box, but from an "3rd party".
-
@lbm_ so if your client on your network is connected to some vpn service, and you resolve whatever to your public IP.. You would travel through the vpn and hit your wan IP from this vpn exit IP.. So it would be like any other port forward your doing. So how would nat reflection come into play?
Nat reflection is when you hit your wan IP from an IP on your lan side.. And need to be reflected back in..
-
Its a splittunnel VPN, not full tunnel, so only traffic where routes are applied are using the VPN.
So the traffic when on VPN, resolves to the external IP address of the host, since DNS are pushed to the client, forcing my own internal DNS not to be used.
-
@lbm_ said in Webserver logs shows pfsense IP instead of LAN IP:
forcing my own internal DNS not to be used.
Ok - so you resolve your public IP, so how would that be a split tunnel to get to this public IP you would go through your vpn.. Split tunnel would mean that you don't go through the vpn to get to your local network say 192.168.1/24..
-
@johnpoz said in Webserver logs shows pfsense IP instead of LAN IP:
@lbm_ said in Webserver logs shows pfsense IP instead of LAN IP:
forcing my own internal DNS not to be used.
Ok - so you resolve your public IP, so how would that be a split tunnel to get to this public IP you would go through your vpn.. Split tunnel would mean that you don't go through the vpn to get to your local network say 192.168.1/24..
Why would it go through the VPN? I get DNS pushed from the VPN, which resolves to the external IP address. So the VPN is only affecting the DNS, but theres no route pushed. Other routes are pushed, but they are not in any way related to this. So since it resolves to the external address, and no route is present, it just goes to the pfsense box, where this external WAN IP is present, and then from here to the webserver.
client->pfsense->webserver.The question is, how can this be fixed, when the public IP is resolved, and the request is internal, so that IP(internal ones) are correctly showed in the web server logs, instead of the pfsense IP. Host override will obviously not work since the local DNS cannot be used.
-
@lbm_ said in Webserver logs shows pfsense IP instead of LAN IP:
So the VPN is only affecting the DNS, but theres no route pushed
Ah ok.. That makes sense then.. In that case then sure you would be hitting your public wan from your local IP, and then yes you would need to setup nat reflection.. As to what IP the dest device your sent to would depend on if pure nat or not and your settings..
-
Yes, that was what I thought, and the question initially was regarding why it was not working. But I've found the problem now. I've set it, in the general setting, but NAT Reflection was set individually on each NAT rule. So changes here had no real affect.
Thanks a lot for your time.
