Outbound NAT for OpenVPN Tunnel IP working in 2.7.2 but not in 2.6.0 - why?
-
Hi all,
I have an Outbound NAT rule that maps an OpenVPN Tunnel IP to another private IP.
This works fine in 2.7.2 and the rule looks like this:
In 2.6.0 it does NOT work. The "source part" is a bit different (mapped to another IP here):
Does anybody know why it doesn't work?
How can I make this work in 2.6.0? Any tips?I see one difference in the Routes list. In 2.6.0 the route to the DNS server 1.1.1.1 used for the DNS Server for the OpenVPN interface looks like this:
In 2.7.2 it looks like this:
The Interface used is lo0 for 2.6.0 but for 2.7.2 it is the OpenVPN-interface ovpnc3. So something seems to be different there...
-
@jarlel
What exactly is VPNTRUNK in both cases?
If it's a single interface and subnet I don't expect traffic from VPNTRUNK subnets going out on this interface.What are the network ranges in play?
-
@viragomann said in Outbound NAT for OpenVPN Tunnel IP working in 2.7.2 but not in 2.6.0 - why?:
@jarlel
What exactly is VPNTRUNK in both cases?
If it's a single interface and subnet I don't expect traffic from VPNTRUNK subnets going out on this interface.What are the network ranges in play?
Sorry, should have mentioned that:
VPNTRUNK is the interface assigned to the ovpnc network port.
Network range is any IP in the 10.51.25.0/24 subnet should be mapped to 10.171.86.12 for any host.10.51.25.0/24 is the VPNTRUNK subnet.
-
@jarlel said in Outbound NAT for OpenVPN Tunnel IP working in 2.7.2 but not in 2.6.0 - why?:
Network range is any IP in the 10.51.25.0/24 subnet should be mapped to 10.171.86.12 for any host.
So all outbound connections on this interface should get 10.171.86.12 as source address?
This would require, that the remote endpoint routes 10.171.86.12 to your client IP. Is this even given?Normally you masquerade outbound traffic with the interface address for proper communication, because the remote site only know the route to this, but not to the devices behind.
-
So all outbound connections on this interface should get 10.171.86.12 as source address?
Correct. For all connections coming from the tunnel IP being in the 10.51.25.0/24 subnet (this IP is dynamically assigned from the OpenVPN server, so I don't know which IP it will be. That is why the whole subnet is NATed to the same IP).
Other traffic is NATed to another subnet. It is only traffic coming from the tunnel IP that should be NAT'ed to this specific IP. This NAT'ing works fine, example NATing the subnet 192.168.110.0/24 to 10.171.84.0/24 with the "Bit mask" pool option.
This would require, that the remote endpoint routes 10.171.86.12 to your client IP. Is this even given?
The server side knows this by using the client specific override. The host is listed in the IPv4 Remote Network/s.
Normally you masquerade outbound traffic with the interface address for proper communication, because the remote site only know the route to this, but not to the devices behind.
Yes, I know. The reason I do it like this is that I need to be able to address several different clients
that has the same subnets for their local LANs. I am also mapping the traffic from different clients to different public IPs on the server side based on the NAT'ed IPs. -
@jarlel said in Outbound NAT for OpenVPN Tunnel IP working in 2.7.2 but not in 2.6.0 - why?:
For all connections coming from the tunnel IP being in the 10.51.25.0/24 subnet (this IP is dynamically assigned from the OpenVPN server, so I don't know which IP it will be. That is why the whole subnet is NATed to the same IP)
I see. So this rule is meant for traffic from pfSense itself only, I guess.
I think, this traffic would come out with a source IP out of 127.0.0.0/8, however. So if this is, what you want, try this source network. -
I see. So this rule is meant for traffic from pfSense itself only, I guess.
Yes, it is primarily for the icmp pings to the monitor IP (to check if the link is up) and for requests to the DNS server(s).
I think, this traffic would come out with a source IP out of 127.0.0.0/8, however. So if this is, what you want, try this source network.
I have already tried this but with no luck. On the server side I see the IP 10.51.25.3.
It is a bit strange as it works fine on 2.7.2.... -
@jarlel
Strange. The hybrid or manual mode is enabled for the outbound NAT?And no other rule on this interface is above of this?
I noticed in past with former versions, that it needed to reboot pfSense, to get a new oubound NAT rule to work. Maybe you can try.
-
Strange. The hybrid or manual mode is enabled for the outbound NAT?
Yes, manual mode.
And no other rule on this interface is above of this?
Correct.
I noticed in past with former versions, that it needed to reboot pfSense, to get a new oubound NAT rule to work. Maybe you can try.
Hm, that might be it! I have not rebooted, have tried to clear states and restarted the OpenVPN client. I will try that tomorrow as I don't have access to it from where I am now.
-
I noticed in past with former versions, that it needed to reboot pfSense, to get a new oubound NAT rule to work. Maybe you can try.
Hm, that might be it! I have not rebooted, have tried to clear states and restarted the OpenVPN client. I will try that tomorrow as I don't have access to it from where I am now.
I have now tried to reboot between changes. I have tried any alternative and combination that I can come up with, but still no success on 2.6.0.
When I list the NAT rules from CLI I see a difference between 2.6.0 and 2.7.2:
2.6.0:
nat on ovpnc1 inet from 10.51.25.0/24 to any -> 10.171.86.12 port 1024:655352.7.2:
nat on ovpnc3 inet from <OPT2__NETWORK> to any -> 10.171.86.10 port 1024:65535<OPT2__NETWORK> is named like this automatically and is the "VPNTRUNK subnet". In 2.7.2 it is possible to select the subnet directly from dropdown in the NAT rule setup, but in 2.6.0 I have to enter the network as 10.51.25.0/24 manually.
Hm, how can I make this NAT rule to actually work like it should in 2.6.0? Anyone?
Thanks :-)
-
@jarlel
I tried this out on the predecessor version 2.4.5 running a OpenVPN client, as I don't have a 2.6.
I noticed, it works for accessing IPs on the remote site (ping, DNS), but doesn't work for accessing the VPN servers IP.
So it doesn't work for gateway monitoring, which seems plausible to me, but it works for any other destinations. -
I tried this out on the predecessor version 2.4.5 running a OpenVPN client, as I don't have a 2.6.
I noticed, it works for accessing IPs on the remote site (ping, DNS), but doesn't work for accessing the VPN servers IP.
So it doesn't work for gateway monitoring, which seems plausible to me, but it works for any other destinations.Thanks for assisting, viragomann.
Do you mean it works from internal networks, like NAT'ing a local LAN?
(That works for me in 2.6.0). -
@jarlel
No, I tested it only from the client pfSense itself, since this is, where you have troubles. As NAT IP I configured any unused, outside of local subnets.
I initiated access to the remote site and sniffed the traffic on the VPN interface.
Of course the remote site didn't respond, since it has no route back for the used NAT IP. -
No, I tested it only from the client pfSense itself, since this is, where you have troubles. As NAT IP I configured any unused, outside of local subnets.
Ok, you configured it in outbound NAT? With the OpenVPN tunnel IP's (network) as source?
Can you please share a picture of the NAT rule?I initiated access to the remote site and sniffed the traffic on the VPN interface.
Of course the remote site didn't respond, since it has no route back for the used NAT IP.In which way did you initiate the traffic? I can get traffic through from pfSense itself (like icmp), but it will not do any NAT when initiated from pfSense, unfortunately (in 2.6.0). The DNS server set up under System-General Setup will not work either. Testing DNS lookup from Diagnostics-DNS Lookup also gives just "No response".
-
@jarlel said in Outbound NAT for OpenVPN Tunnel IP working in 2.7.2 but not in 2.6.0 - why?:
Ok, you configured it in outbound NAT? With the OpenVPN tunnel IP's (network) as source?
Exactly.
It's a site2site, so it uses a /30 tunnel network.
In which way did you initiate the traffic?
On pfSense itself I used Diagnostic > Ping and DNS lookup.
ICMP packets with destination 10.0.51.6 (server IP) were not translated, whether the ones from apinger, nor manually initiated ones.
ICMP packets to a device behind the remote endpoint were nated though.
The remote LAN IP is stated as DNS server in the general settings. So it is requested, when doing a DNS lookup. These packets were translated to the stated IP in outbound NAT as well.
Note that this is a 2.4.5.
-
Hi again,
I believe I have made it work now. The only thing I did was to push a route from the server side, like
push "route 192.168.123.0 255.255.255.0" (this is a route to a LAN on the VPN server). I am not using this subnet in any way seen from the client side, so kind of strange that just adding a route made the NAT setup work.That made the client side use the ovpnc interface instead of lo0. Now both the internal monitor pings and the DNS lookups via the ovpnc interface translates correctly.
Thanks again for the assistance, viragomann.