New Member

Question

Fixing IP overlap using virtual IPs

12 replies
5818 views

Hi everyone. I'm new to the community and Fortinet in general. And it's exciting learning about all of the features of the fortigate.

This is likely a very simple issue to many of you.

I'm facing an predicament where some users are trying to access internal office resources abroad using SSL VPN, but seem to be facing a conflict because their home networks fall into the same subnet (192.168). Rather than re-addressing their entire home, or the office network, I've been following this guide which suggests virtual IP mapping might be an elegant solution: https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-SSL-VPN-with-overlapping-subnets/ta-p/189886

However, when I test it myself, I can connect to the VPN tunnel, but none of the local IP addresses get mapped to the new address ranges that I specify.

Admittedly, I get a bit confused by the terminology used in the UI, (such as "External IP address range") I'm not exactly sure which IP range I should put there. Is it the VPN tunnel IP ranges, or the user's home network range, or something else?

Any help or advice would be greatly appreciated.

amrit

Staff & Editor

Example:

SSLVPN remote user's local wifi subnet is 192.168.0.1/24 and the internal office lan is also 192.168.0.1/24

In this case, the internal IP range should be 192.168.0.1-192.168.0.254 the external IP address is the address you will map with your internal range. That means this address(external) will be installed on the user's PC and can be verified with the "route print" command on Windows. The purpose of the external address is to provide a unique address to the user that should not conflict with the local ip address space of the user. When user ping the address 172.16.0.1 , the fortigate will translate this address to 192.168.0.1 and will send the request to your internal network via the policy and VIP.

4wheelsAuthor

New Member

Thank you. Although I’m still a bit confused by what you mean with, “this address(external) will be installed on the user's PC”

So I should add the external IP addresses as something unique? Does it need to be a specific alternate range or can it be arbitrary?

I’ll test this again and report back the results

fdsantos

Staff

Hello,

For the external IP address, it would be the one that will be used by the SSL VPN overlapping users to access the real servers internally.

Here is the scenario below:

External IP address 172.16.0.1

Internal IP address 192.168.0.1

For SSL VPN overlapping users to reach 192.168.0.1 on your internal network, they need to reach 172.16.0.1 instead of using the internal IP address.

You can assign any external IP address on your settings as long as they are not used on your network.

Thank you.

Hong_FTNT

Staff & Editor

Hi @4wheels,

"External IP address range" should be a dummy subnet (an unused subnet). So you are connected to the VPN, you will access that dummy subnet instead of 192.168.x.x. It will be mapped by the FortiGate accordingly.

Regards,

4wheelsAuthor

New Member

Thanks everyone. I'm still having an issue. It seems like the guide I linked above is missing a crucial step. How should I create the source IP pools group that is shown in the screenshot under step 2?

fdsantos

Staff

Hello,

I assume you are referring with the setting below as the part 2 in the documentation.

You need to go in User & Authentication -> User Groups and create the user group that you will be using in the Authentication Portal in VPN -> SSL VPN Settings.

Thank you.

4wheelsAuthor

New Member

Sorry, I meant the source IP pool in step three (I couldn’t edit my post)

I need to know how these were created at what settings were used:

thanks.

4wheelsAuthor

New Member

With the lack of an answer, I went ahead and put my land IP range into that field from the screenshot above. Apparently that was the wrong thing to do because I lost connection to my FortiGate and FortiAp immediately And haven’t been able to get it back since even after two factory resets

4wheelsAuthor

New Member

So I finally got everything back, and this experience has left me dazed and even more confused.

Firstly, I'm confused as to why simply creating a new IP pool (without assigning it to any interface, user, or group) was so destructive.

Secondly, anyone new enough to NEED to follow the guide that I'm trying to follow, should not be left to guess by trial and error on any steps, let alone something so damaging.

Thankfully this was just my home lab environment, but it could've been much worse. I'll eagerly await someone to guide me on what to do here so I can finish setting up the fix for IP overlapping, since I definitely don't want to reset everything again.

Sign up

Login with SSO

Login to the community

Login with SSO