Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 538
  • Last Modified:

VPN ACL Traffic

Hello experts. I have a FortiGate 110C and a Cisco 1721 which have a successful IPSEC site-to-site tunnel connected. The FortiGate is the "server/host' and the 1721 is the branch office.

Communication from the Internal port on the the 1721 to the Internal port on the Fortigate passes successfully. I can RDP, ping, browse shares, etc. from the 1721 to the Fortigate. However, if I try to ping www.google.com from an internal client on the 1721 I can see that the ping resolves www.google.com to an IP, but there is no reply.

Also, I cannot RDP, ping, browse or otherwise connect to the 1721 from the Fortigate's Internal network. For those who are visual learners, this is what is happening:

10.10.10.0 0.0.0.255 -----> 10.10.0.0 0.0.255.255 works great
10.10.0.0 0.0.255.255 -----> 10.10.10.0 0.0.0.255 not so great

Is this an ACL problem on the 1721 or is this a firewall policy (Fortigates version of ACL) on the Fortigate?

I have a 1841 connected to the Fortigate with identical configs and it works great with no problems which tells me that there could be something on the 1721's end. It could be the Foritgate too I guess, but that setup is identical for both device as I have them grouped with the same settings, etc.
0
swcrook
Asked:
swcrook
  • 4
  • 3
1 Solution
 
asavenerCommented:
At first blush, it looks like a subnetting issue.

"10.10.10.0 0.0.0.255 -----> 10.10.0.0 0.0.255.255 works great
10.10.0.0 0.0.255.255 -----> 10.10.10.0 0.0.0.255 not so great"

10.10.0.0/16 overlaps with 10.10.10.0/24.  Devices on the 10.10.x.x subnet will think the 10.10.10.x devices are directly connected, and will not try to route over the VPN.

The reason connections work from the branch is that the Fortigate uses its own MAC address when communicating with the servers at the main site.

0
 
asavenerCommented:
Try adding an explicit route on one of the devices at the main site, and see if it can connect.  (Windows assigns a metric of 20 for directly connected subnets; adding an explicit route should override the entry in the routing table.)

At a command line:  route add 10.10.10.0 mask 255.255.255.0 fortigate-ip-address
0
 
swcrookAuthor Commented:
The explicit route didn't help, but I can't exclude it all together. On the 1841 with similar settings, the subnet is /24 and it can browse the internet through the VPN, but that network can not be connected to either. My first statement was inaccurate, so it appears it could be a subnet issue.

Can you tell me why MPLS/BGP lets me connect from the main to all branch sites which have a /24 subnet?

Any other ideas or is it possible that the explicit would work but there is a blockage somewhere of teh traffic? Thanks
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
asavenerCommented:
I'm not familiar enough with the Fortigate product.  With a Cisco, I'd suspect that the traffic was somehow being caught by the NAT rules.
0
 
swcrookAuthor Commented:
Does a VPN tunnel inherently allow traffic both ways? From what I can tell it DOES NOT, but is does allow outgoing traffic?
0
 
swcrookAuthor Commented:
I am going to change the subnetting to see if that resolves the issue. I will let you know, thanks.
0
 
asavenerCommented:
A VPN tunnel does usually allow traffic in both directions.  But that doesn't mean an access-list, packet filter, or stateful firewall can't block it somewhere.
 
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now