So we’ve been following this post and it has been working great to forward all PepVPN client traffic through the firewall. However, the Balance also has an IPSec tunnel to a 3rd party. When trying to get to devices inside that IPSec VPN, the firewall never sees the traffic. Adding the 0.0.0.0 route to the firewall should forward “all” PepVPN traffic through the firewall but could there be an exception if the Balance sees that the destination is in an IP range that’s in one of it’s IP Sec tunnels?
Your diagram is perfect. Traffic from subnet B does get to subnet C but it doesn’t go through subnet A so their is no firewall/content filtering capability. My hope was that the “route 0.0.0.0/0” rule would route all traffic through subnet A and then if we didn’t want that we could use Outbound Policy in Expert mode to add a rule above the PepVPN rule to essentially by-pass the firewall. But we have clients that want all traffic to go through the firewall so it can be logged and AD group based policies are applied.
I know where you come from. However, this is the expected behavior since this is interbranch communication. We don’t expect to forward such traffic to another hop even static route 0.0.0.0/0 was configured.
May I know how many SpeedFusion and IPSec peers are connected to the Balance 580? This allowed me to advise whether any alternative solution for this.
We have multiple clients were we are having this same challenge with whether traffic is actually being forwarded to the firewall as expected or not. I’ll just focus on one right now as it leads me to more questions… We have 2 PepVPN profiles in InControl with the same hub. The first has 11 endpoints and with those the options is NOT checked to “Forward All Traffic to the Hub”. The 2nd profile is for remote offices and has 2 endpoints and the option IS checked to forward all traffic to the hub. Here are some questions to make sure we understand how it works.
So if the Balance hub has an IPSec tunnel, traffic to that Segment C (in your diagram) always goes direct and ‘short circuits’ Segment A regardless of the 0.0.0.0/0? If we add a specific route forwarding to the firewall, will they address that traffic?
Does SIP traffic also “short circuit” the 0.0.0.0/0 route? I ask because when we enabled “route all traffic through the hub”, web traffic did go through the hub and to the firewall and then back out to the Internet as expected. However, the cloud based SIP phones did not do that as we could see that the phones were registered with each branches public IP rather then the expected main office (hub) public IP.
This is an observation…but on the endpoints where the VPN was NOT checked to “route all traffic through the hub” and we have a 0.0.0.0/0 rule, I do see the traffic going to a IPSec tunnel on the balance going through the firewall. To avoid that, I have to have an Outbound Policy that’s ‘above’ the PepVPN policy. Then if we CHECK 'route all traffic through the hub", traffic to an IPSec network did not honor the 0.0.0.0/0 rule (just as you said it would in your post). We need to do some more testing but I’m almost positive that traffic heading to an IPSEC network did indeed go through our firewall if “route all” was UNCHECKED.
Related to #3, is it okay to have 2 PepVPN profiles with the same hub? Could a change to ‘route all’ on one profile be effecting the other traffic?
Look like this is nothing to do with the route 0.0.0.0/0 on central hub Balance580. SIP traffic was local break-out at remote side. I suspect the PepVPN tunnel was down before. Hence, SIP traffic was local break-out.
The is strange and not expected. Please share the screenshots below:
Outbound Policies (Network > Outbound Policy > Rules) on remote site and central hub.
IPSec settings on central hub Balance 580 (Network > IPSec VPN > Click IPSec profile).
If the info are sensitive, please help to open ticket.
Do you mean configure 2 PepVPN profiles between a remote site and central hub? If so, this is not possible.
We have 2 PepVPN profiles in InControl with the same hub. The first has 11 endpoints and with those the options is NOT checked to “Forward All Traffic to the Hub”. The 2nd profile is for remote offices and has 2 endpoints and the option IS checked to forward all traffic to the hub. Here are some questions to make sure we understand how it works.