[Solved] IPSEC VPN with overlapping subnets

2»

Comments

  • zyman2008
    zyman2008 Posts: 197  Master Member
    First Anniversary 10 Comments Friend Collector First Answer
    Well,
    then you need a split DNS server or DNS view for the VPN clients.

  • DW_Informatica
    DW_Informatica Posts: 10  Freshman Member
    First Anniversary First Comment
    Ok, I was expecting it... the firewall-side issue is solved anyway. Thank you very much zyman2008 !


  • Floppy
    Floppy Posts: 1
    First Comment

    If I could be so brutal to continue this thread for my own sake ...

    I understand I might have to create a complete new thread for my question, but here it goes.

    I am trying to set up a SecuExtender (IPSec VPN Client) situation towards my USG40 at work with 192.168.1.0/24 subnet. That is an easy task in itself and I can for instance get the IPsec Clients to get 10.3.80.0/24 on the "Mode Config Address Pool".

    My main question is how can I make other devices on the subnet and even the firewall itself see the clients as a small ip-range of 192.168.1.180-192.168.1.189 instead of 10.3.80.0/24? The point is that I have a site to site between my USG40 and the provider of our door access system, and I am not in control over their firewall... So I cannot add my 10.3.80.0/24 in their policy routes for traffic return ... Therefore I need to fake my VPN Clients (for instance my laptop running on mobile broadband or actually at home) to seem to be in the actual internal network of 192.168.1.0/24 (the range 192.168.1.180-189 is reserved for this if I get it to work)...

    So that if my VPN client with 10.3.80.101 tries to contact my Raspberry Pi @ 192.168.1.24 the Pi would see the client as 192.168.1.183 for instance ... and thus If I try to reach the other end of the site to site VPN @ 10.10.20.50 it will also see my 192.168.1.0/24 network.

    I've tried for several hours now to read and figure this out if it's possible to relay traffic from my 10.3.80.0/24 to be SNATed to range 192.168.1.180-189 and policy route it to the correct next-hop VPN if destination is the range ... No luck.

    I pretty easy list of directions if this is even possible, would be greatly appriciated. The VPN stuff works as it is now with clients getting 10.3.80.0/24 IP on auto-configuration. It's the masking and hiding to make it look as it's a part of the 192.168.1.0/24 to others (at least to the other VPN-tunnel if not all)

Security Highlight