IPSec VPN traffic works only one way

[yrvie]

Hello everyone,

I'm having a bit of trouble getting our VPN to work properly. Both routers are Fortigate 60B running 4.0MR3P18. The tunnel comes up fine and I can initiate any type of traffic from the branch network to the head office network (i.e. ping, VMware, active directory, file sharing, etc.) but if I try to do the same from the head office to any device on the branch network, it doesn't work at all. I've tried pinging from the head office FortiGate and it ends up being unreachable every time.

I have another VPN connection for FortiClient and iOS devices I set up earlier using the CLI that is set with an ipv4-start-ip, and an ipv4-end-ip (192.168.4.0-10) which works fine: traffic works properly from either end and a static route for the individual IP assigned shows up in the routing table as the client connects, then is removed automatically as the client disconnects. Windows computers on the head office network know to route 192.168.4.x through the router. The new branch office VPN has identical firewall policy settings as the VPN that works and I've triple checked everything, including NAT settings to make sure they match those of the working VPN connection.

The head office network is on 192.168.1.0/255.255.0.0 and the branch office is on 192.168.10.0/255.255.255.0 and I'm wondering if that has something to do with the issue. But I'm confused as to why the working VPN that is set to automatically issue IPs and creates entries with a /32 netmask in the route table automatically works fine, but the new branch office VPN with another Fortigate does not.

What I did:

- Set up a static route to the branch firewall (192.168.10.0/255.255.255.0) on the host firewall which shows up in the routing table. 

- Made sure firewall settings are identical to that of the working VPN and are set to allow all traffic from the head office network to the branch network.

-The head office has a static IP and the branch office is a dialup client, and the quick mode selectors are as follows:

Branch office:

Source: 192.168.10.0/255.255.255.0

Destination:0.0.0.0/0.0.0.0

and both on the head office network to 0.0.0.0

The setup seems correct to me but obviously there must be something I'm missing. 

Any help is greatly appreciated and more info will gladly be provided if needed, I'm not sure if I included everything!

[Iescudero]

Hello! can you post your VPN configuration?

IKE Phase1

CLI:

config vpn ipsec phase1-interface

or

config vpn ipsec phase1

edit "NAME_OF_YOUR_VPN"

IKE Phase2

config vpn ipsec phase2-interface

or

config vpn ipsec phase2

"NAME_OF_YOUR_VPN"

Also, In the Head Office firewall, do you have a route to 192.168.10.0/24 set device to your VPN?

If you want, submit your policys and static routes from both sides, just for this VPN only.

[rwpatterson]

Simply put, your head office subnet contains the branch office subnet. (192.168.10.x/24 is part of 192.168.x.x/16) The head office Fortigate doesn't see a need to route when that smaller subnet is inside it's walls, so to speak. You will need to do some sort of re-subnetting to get this to work as desired by either changing a subnet mask (head office), or changing out a subnet all together (pick one). A less desirable solution would be to D-NAT the remote office so it can be reached, but that's not the direction I would go.

My two bits.

[yrvie]

rwpatterson wrote:

Simply put, your head office subnet contains the branch office subnet. (192.168.10.x/24 is part of 192.168.x.x/16) The head office Fortigate doesn't see a need to route when that smaller subnet is inside it's walls, so to speak. You will need to do some sort of re-subnetting to get this to work as desired by either changing a subnet mask (head office), or changing out a subnet all together (pick one). A less desirable solution would be to D-NAT the remote office so it can be reached, but that's not the direction I would go.

My two bits.

I understand, and I think you're absolutely right. I'd have to change the head office subnet to 255.255.255.0, or similar so that the computers know what to route. If I change the subnet mask on the branch network to 255.255.0.0 I can't access any remote resources even though static routes are configured.

I just don't understand why the VPN at the head office for mobile devices that issues IPs on 192.168.4.0 works fine both ways, when it's configured on the same subnet as the head office network (255.255.0.0)? How does the Windows server on the network and the FortiGate know it needs to route those packets over the VPN when they're on the same subnet? I didn't add a route manually on the Windows server so it's doing that entirely on its own.

To be quite honest, the only reason the head office network is on 255.255.0.0 is to partition the network so that servers and other networking gear are separate from the rest of the computers of the network - I'll have to find a different way of doing this. 

[yrvie]

Problem solved:

So I changed the subnet mask on the head office internal network on all devices and the FortiGate itself to 255.255.255.0 (/24). I made sure there is a static route in place on the head office network to 192.168.10.0/24 and set to the VPN's interface. 

I am now able to communicate both ways, I just had to uncheck "NAT" in the firewall policy from internal to the VPN connection on the head office VPN to match exactly the same as the branch FortiGate is connected.

So the issue was a combination of the subnet mask on the head office network not allowing routing to take place (255.255.0.0) and the incorrect NAT setting on the firewall policy. 

Thanks again!

[rwpatterson]

Glad I could help. For what it's worth, you could change the mask to /23. That would give you two 24 bit networks so to speak. (192.168.0.0-192.168.1.255). What is generally recommended by most experienced members here is that you stray away from using the 192.168.1.x, 192.168.2.x, 192.168.3.x, and 192.168.0.0 networks since so much gear comes defaulted there. If in the future you need to VPN to a third party that was either lazy or inexperienced and left the same network as yours, you now have a large hurdle to overcome.

Another pearl of wisdom.

Enjoy