Virtual public IP routing OK from outside but gives issue from VPN !
-
(First of all, if this topic does not belong to this routing category, feel free to move it)
Here is the setup in a few words :
pfSense version 2.3
External self IP : xx.xx.xx.72 (WAN)
Virtual IP : xx.xx.xx.75
LAN : 10.0.0.0/24
Webserver : 10.0.0.5
VPN L2TP/IPSec IPs : 192.168.xx.xx /28
The entire bunch runs on an ESXiNAT : external virtual IP .75 to internal 10.0.0.5
The situation :
1. When coming from the outside to the Virtual IP .75 which is public IP, everything is fine, the website is answering on the external as expected.
2. When connected through the VPN (L2TP), the LAN is accessible as expected, nice. Even the 10.0.0.1 of the WebGUI of the pfSense.
BUT … when I try to reach some virtual IP (public IP) like xx.xx.xx.75 (or the equivalent by DNS FQDN), what I get is :- WebGUI
- redirected on HTTPS (which is normal due to settings)
Seems like the FW says "oh, I know that IP, it is 'directly connected' and it is one of my own IP's so here it is, be welcome !" instead of applying NAT rules to pass through to the backend server behind.
The question is : how to make the public IP work as from the outside and getting the NAT working even from the VPN ? Where is the issue ....
I don't want the WebGUI to answer on the Virtual (public) IP when on the VPN.This issue starts to drive me crazy :-)
Any input will be welcome.
/O.
-
Obviously your pfSenses WebGUI is listening to port 80 and/or 443 on requests from internal networks. This can be changed in System > Advanced > Admin access.
However, accessing an internal host from an internal network by using its public address isn't possible without further ado.
You can either set up a split DNS the get the public FQDN resolved to internal address or you use NAT reflection. NAT reflection can be set selectively in each NAT rule or globally in System > Advanced > Firewall & NAT. -
Thank you for your answer.
It is what currently happening … reaching the GUI from the inside on any of the Virtual IP's that are meant to be NAT to some LAN server (common way of NAT'ing)
The only things I set up are :
- NAT on those 3 Virtual IPs
- some rules to have it accessed from the outside
To get it maybe much more clear, here is some weird behavior linked :
Situation :
Ping from my laptop connected onto the VPN (L2TP/IPSec) with some 192.168.x.x address to a public IP that can be reached perfectly from the outside 91.134.183.74 (em0) which is NAT'ed to 10.0.10.4 in the LAN (em1).Here is the output :
- taken on the if l2tp0 :
tcpdump -n -i l2tp0 host 192.168.x.x and port not 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on l2tp0, link-type NULL (BSD loopback), capture size 65535 bytes10:10:46.586013 IP 192.168.x.x > 91.134.183.74: ICMP echo request, id 41134, seq 77, length 64
10:10:47.590574 IP 192.168.x.x > 91.134.183.74: ICMP echo request, id 41134, seq 78, length 64
10:10:48.594678 IP 192.168.x.x > 91.134.183.74: ICMP echo request, id 41134, seq 79, length 64- taken on the LAN (to see if it reaches the targeted server) :
tcpdump -n -i em1 host 192.168.x.x and port not 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes(…. NOTHING here)
- taken on the WAN interface :
tcpdump -n -i em0 host 192.168.x.x and port not 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes10:09:58.470654 IP 91.134.183.74 > 192.168.x.x: ICMP echo reply, id 41134, seq 29, length 64
10:09:59.472724 IP 91.134.183.74 > 192.168.x.x: ICMP echo reply, id 41134, seq 30, length 64
10:10:00.475666 IP 91.134.183.74 > 192.168.x.x: ICMP echo reply, id 41134, seq 31, length 64
10:10:01.476897 IP 91.134.183.74 > 192.168.x.x: ICMP echo reply, id 41134, seq 32, length 64
10:10:02.474787 IP 91.134.183.74 > 192.168.x.x: ICMP echo reply, id 41134, seq 33, length 64
10:10:03.476701 IP 91.134.183.74 > 192.168.x.x: ICMP echo reply, id 41134, seq 34, length 64
10:10:04.480793 IP 91.134.183.74 > 192.168.x.x: ICMP echo reply, id 41134, seq 35, length 64Hereby the routing table of the FW :
Internet:
Destination Gateway Flags Netif Expire
default 91.134.183.254 UGS em0
10.0.10.0/24 link#2 U em1
10.0.10.1 link#2 UHS lo0
91.134.183.0/24 link#1 U em0
91.134.183.72 link#1 UHS lo0
91.134.183.73/32 link#1 U em0
91.134.183.74/32 link#1 U em0
91.134.183.75/32 link#1 U em0
91.134.210.0/24 link#1 U em0
91.134.210.4 link#1 UHS lo0
127.0.0.1 link#6 UH lo0
192.168.x.x link#7 UHS lo0
192.168.x.x link#7 UH l2tp0Seems like there is at least an issue here as the FW seems to send that traffic to the internet … which could be acceptable if at least they came back ...
.. or, better, to have the NAT rules applied on those addresses.
I did not add those routes at any point and cannot have them deleted neither.- Here the routing entries on the laptop :
91.134.183.72 10.0.0.1 UGHS 5 13449 en0
91.134.183.74 link#10 UHWIi 1 1199 ppp010.0.0.1 is the default GW of my CheckPoint here at home which is correct and works fine.
But for the other WAN IP, it sends it to the tunnel. Same story, I did not add those records. The VPN connection propagated it here for me.So the first issue is pretty clear : the FW is sending its traffic onto the wrong interface (question #1 : how to get rid of that strange routing entries)
But the second one is at least as weird : the FW seems to answer to a request to 91.134.183.74 instead of transferring it to the according server on the LAN. He definitively things he is the guy that own that IP (which is technically correct , except the NAT part)
I already re-installed the entire pfSense twice from scratch and always the same issues … depression is watching me ...
Thanks
/O.
[edit]
Hmmmmm …. sounds like Reflection had not been enabled on that 1:1 NAT entry ...
So from the LAN, it is working now.But still not from the VPN. It is allowed by the rules but a ping to some public VIP entering the l2tp0 if ig getting out to the WAN ... :-/