Skip to main content
ankitsharma
ankitsharma
New Member
September 9, 2015
Question

IPSEC VPN URGENT HELP NEEDED

  • September 9, 2015
  • 1 reply
  • 5258 views

HI All

 

We are using 4.0 mr3 Os of fortigate. I have an urgent issue regarding IPSEC. 

 

REMOTE SUBNET: 192.168.5.0 across the internet

 

LOCAL SUBNET: 192.168.2.0

 

The client has a printer and a scanner in the 192.168.2.0 subnet that they want to access from the remote side. When the clients print from the remote side to the local side, the printing works fine. But when the scans need to send from local subnet to the remote subnet, it gets dropped.

 

The firewall has been setup for allowing ipsec from 192.168.2.0 subnet to 192.168.5.0 subnet. The policy allows both inbound and outbound traffic and is also set for inbound nat. There is one 192.168.0.0/16 route that points towards the inside.

 

I ran a flow capture on the firewall and I could see that the traffic from 192.168.2.xx was trying to get to the 192.168.5.xx with the correct ip addresses. But I am unable to understand why it does not meet the IPSEC policy and go through the tunnel. When we began testing I could see that the traffic was hitting the FW but instead of meeting the ipsec policy, it was being dropped by the implicit rule. So what I did was put in a policy that allows traffic from those particular ip addresses to allow all traffic and all services. This is not a ipsec policy. Just a general one.

 

Now what happens is that the CPE from the 192.168.2.0 subnet side sends traffic to my FW destined to 192.168.5.0. But since the FW has a /16 route back to that CPE, the traffic just bounces between these 2 devices and dropped due to ttl timeout. I am in a fix how to solve this.

 

I am unable to understand why the traffic from the correct source and destination fails to meet the ipsec policy and instead looks in the routing table and gets dropped.

 

I have tried to be as specific as I can regarding the issue. Any help in this matter will be appreciated.

 

 

Thanks

1 reply

rwpatterson
rwpatterson
New Member
September 10, 2015

Do this: Change the subnet mask from 16 bit to 24 bit. A 16 bit subnet covers both sides of the tunnel, which is why your traffic bounces back and forth until death does it's part. Change that subnet mask on both sides of the tunnel in the IPSec phase 2, then restart the tunnel from both ends. After that, try the scan again.

 

After rereading, just change the routes to be 24 bit instead. 192.168.0.0 is common with a 16 bit route as well.

 

Remember, when creating tunnels, policies, anything in the FGT, Broad = Bad, Granular = Good! Avoid the 'any' interface unless it's the only thing left! Being lazy now equates to more work later.

ankitsharma
ankitsharmaAuthor
New Member
September 10, 2015

rwpatterson wrote:

Do this: Change the subnet mask from 16 bit to 24 bit. A 16 bit subnet covers both sides of the tunnel, which is why your traffic bounces back and forth until death does it's part. Change that subnet mask on both sides of the tunnel in the IPSec phase 2, then restart the tunnel from both ends. After that, try the scan again.

 

After rereading, just change the routes to be 24 bit instead. 192.168.0.0 is common with a 16 bit route as well.

 

Remember, when creating tunnels, policies, anything in the FGT, Broad = Bad, Granular = Good! Avoid the 'any' interface unless it's the only thing left! Being lazy now equates to more work later.

Hi 

 

Thanks a lot for the reply. The subnet masks in the phase 2 is set to /24 on both sides. There is just another static route in the routing that is /16. So do you mean I should change that?

 

Thanks and Regards 

 

Ankit

rwpatterson
rwpatterson
New Member
September 10, 2015

Yes. The mask in the route.

Terms & ConditionsAccessibility statement