Make Hosts available that are not in a phase2 subnet
-
Hi there,
I want to make two local DNS servers available to a remote site which is connected via IPSec VPN - while the DNS servers reside in a local subnet that is not available to the remote site.
The setup is:
- Local LAN1: 10.10.10.0/24 (not available to the remote site)
- with DNS servers at 10.10.10.10 and 10.10.10.20
- Local LAN2: 10.120.0.0/24 (available to the remote site)
- Remote site: 192.168.0.0/16
VPN and stuff works fine so far.
Now I created a 1:1 NAT on IPSec interface which NATs- 10.120.0.250 -> 10.10.10.10
- 10.120.0.251 -> 10.10.10.20
I was expecting to make the internal DNS servers available to the remote site on 10.120.0.250 and 10.120.0.251 this way. I tried some more stuff but wasn't able to get it working.
I think the problem is, that the destination of the traffic is at 192.168.0.0/16 when the DNS server replies ans pfSense will drop the traffic because 192.168.0.0/16 is not available from 10.10.10.0/24Adding 10.10.10.0/24 to the VPN is not an option, because it is already in use at the remote site. Maybe I could also NAT the whole network to the remote site, but I wanted to keep things easy...
Do you have any ideas how I could tackle this? :)
- Local LAN1: 10.10.10.0/24 (not available to the remote site)
-
@theshmike
Are you talking about a routed IPSec?
If so, what network do you have in phase 2 at all? -
Yes, it's routed IPSec.
Currently, theres only 10.120.0.0/24 in phase 2:Please ignore the last 2 entries, they are disabled and are some remainings of my attempts to solve the problem :)
-
@theshmike
I assume, this won't work with BINAT if you still need to connect the 10.120.0.0/24 network with the remote LAN.The only way I can think of, is to add simple NAT port forwarding rules to the IPSec interface. But I have never done this.
Just select IPSec at interface, set the destination to "single host or alias" and enter 10.120.0.250 in the next field and 10.10.10.10 for redirection. -
Yes, I also tried this approach but it hasn't worked also
I also added 10.120.0.250 as virtual IP and I was able to ping it from the remote site, but still no luck when I try to use DNS with nslookup@10.120.0.250... -
@theshmike
Adding as virtual IP can be done, but isn't necessary, since the IP is routed to this site anyway.However, ensure that the DNS servers are responding to the requests from the remote site. Consider that this access is coming from "outside". So possibly you have to allow it on the servers firewall and add it to DNS servers ACLs.
To investigate sniff the traffic on LAN2 and check if DNS requests are forwarded properly.
-
DNS requests are reaching the server and the server is answering the requests.
When I query DNS server 10.120.0.250 from the remote site, on IPSec interface
- IP 192.168.1.1.53323 > 10.120.0.250.53: UDP, length 25
while on LAN1 (where the DNS server resides)
- IP 192.168.1.1.53323 > 10.10.10.10.53: UDP, length 25
- IP 10.10.10.10.53 > 192.168.1.1.53323: UDP, length 118
But the anser never arrives at the IPSec-Interface. I tried to do outbound (source) NAT for all traffic from 10.10.10.10/32 to 192.168.0.0/16 with source translation to 10.120.0.250 but still no luck - can't see the answers on an IPSec trace...
-
@theshmike said in Make Hosts available that are not in a phase2 subnet:
query is already NATed on the trace on IPSec-interface
IPSec is a bit magic, it isn't an interface like others.
The outbound NAT only affects outbound traffic, not responses on incoming traffic. So sadly no use here.
I was hoping, it would work this way. But obviously the kernel only route strictly according to the P2.
As I got you, you cannot do changes on the remote site. Maybe it works if you blow up your sites network in P2 to 10.0.0.0/9. But that could lead in some conflicts with other routes.
-
I finally managed to do it by adding 10.10.10.0/24 to phase 2 at local and remote site.
I should have been more concrete in the initial problem description.
The problem was not, that I could not add a phase 2 entry at the remote site, but that there is another router behind the vpn remote gateway and the remote clients.
And it would have been impossible for me to add routes on this router.Now I added 10.10.10.0/24 as phase 2 just to bring up the tunnel and force the kernel to route the traffic (DNS responses) over IPSec. In this configuration, native communication between 192.168.0.0/24 and 10.10.10.0/24 is still not possible, but port forwarding from 10.120.0.250>10.10.10.10 now works like a charm
So it's more like a hack than a solution, but it's not stuppid als long as it works
Thank you for your support and merry christmas!