VPN routing from one community (Route based VPN) -> (Domain based VPN)

[Sky]

Hi All,

We are trying to make possible communication from a Route Based VPN community to a domain based VPN community.

Route based VPN is established with numbered VTI interfaces and the only thing we are missing is that traffic should go correctly routed to the domain based VPN.

For all other communications that are working we are using directional  match condition like the below:

• To and from the VPN Community via VPN routing (Community1 => Community1)
• From the Community to the local VPN domains (Community1 =>internal_clear)
• From the local VPN domains to the VPN community (internal_clear => Community1)

Now in order to route the traffic from one community route based vpn (Community1) to the other related to the domain based vpn (Community2), we have applied a directional  match condition (Community1 => Community2).

It seems that this is not working and traffic is not matched by this access rule.

Our cluster is having a 2 x 5800 appliances on version R80.30 (managed by a SMS on version R80.30) which is defined in both of the communities and the other parties are having a Juniper SRX for Community1 and a Cisco ASA Firewall for the Community2.

Can someone help on this situation, maybe you have faced this behavior previously?

Thank you.

[PhoneBoy]

The following SK may be helpful in this case: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 

[Sky]

Thank you for pointing out to this SK, but there is no encryption domain clash between the route based vpn and the domain based one. Maybe I have to better explain it below:

(192.168.1.0/24) Gateway-1 >>> Route based VPN >>> Gateway-2 (0.0.0.0) VPN community-1 -> AS a HUB

HUB ->(0.0.0.0) Gateway-2 >>> Domain based VPN >>> Gateway-3 (192.168.3.0/24) VPN community-2

There is a source NAT rule for the encryption domain network of Gateway1 being hidden behind the HUB using the network / IP 192.168.2.1 when traffic is flowing on the tunnel with Gateway3 (192.168.3.0/24), where 192.168.2.0/24 is defined as the encryption domain for the Gateway2 (HUB) in the configurations made on Gateway3.

Orig. Src: 192.168.1.0/24

Orig. Dst: 192.168.3.0/24

Tran. Src:192.168.2.1

--Everything else original (no translation)

Now just to explain that when source would be another VPN domain based it is working because basically we put the 2 respective community in the VPN column and the traffic routes from one community to the other and the traffic is flowing with no issues.

The problem we have is to make in work by using directional match conditions, hoping that this is not the wrong way to follow.

I would appreciate any other thoughts on this and sorry for the   late response to the thread.

Thank you

[PhoneBoy]

I'm sorry, I'm not sure I understand this statement: "The problem we have is to make in work by using directional match conditions, hoping that this is not the wrong way to follow"

Does this mean you're using Directional VPN rules?
I have a feeling this might not work in the case of mixing domain and route-based VPNs, but could be wrong about that.
In any case, we'd probably need to see the directional VPN rules in question or you might want to take this with the TAC.

[Sky]

Hi,

Below there is an example of the directional match rules we tried:

We have tried by using different combinations with no luck:

1. We tried first the below:

• (Community1 => Community1)
• (Community1 =>internal_clear)
•  (internal_clear => Community1)
• (Community1 => Community2)

2. Then we tried just one conditionas below:

• (Community1 => Community2)

Not sure what should be the correct combination of these matches and of course not sure at all if this is the way to go.

I did not find any specific example, a case is already opened and waiting for the engineer feedback on this.

Thank you for your support so far.

[PhoneBoy]

What happens when to try and initiate traffic from Community1 to Community2 in this case?
Any logs seen or debugging done?

[Sky]

Logs where showing that traffic was traveling through the first route based VPN tunnel, but not able to make a VPN route to the other domain based tunnel. Actually we were in rush and changed back to domain based VPN which worked immediately.

Now since we will have another situation similar because we can not avoid this time the route based VPN I was asking if someone was facing this similar setup and maybe have any idea on what we are doing wrong.

[Bob_Zimmerman]

With route-based VPNs, you have to define a community for the negotiation parameters. Traffic never matches that community directly, though. The firewall perceives it as not encrypted in any VPN. Thus, I suspect your VPN match condition in that rule will never be met.

[Sky]

Hi,

Logs where showing that traffic was traveling through the first route based VPN tunnel, but not able to make a VPN route to the other domain based tunnel.

I was thinking that the way we have implemented the directional match conditions were wrong, but at this point I'm not sure if that is something we can be achieved at all by using those terms.

[Bob_Zimmerman]

It's definitely possible. For the route-based peer, the encryption domain will need to be an empty group. This prevents traffic involving it from matching domain-based VPN logic.

For the center gateway, the encryption domain will need to include the networks behind the route-based peer and the networks local to the center gateway.

For the domain-based peer, the encryption domain will need to include the networks local to the domain-based peer.

Remove the directional match settings. Traffic from the route-based peer will not match any VPN domain. VTIs act like a really long ethernet cable between the two peers. In fw monitor terms, each incoming packet from the peer hits i-I-i-I-o-O. The first i-I is the encrypted traffic on the actual interface routing between the peers. It hits the OS and gets decrypted, then gets injected into the VTI, where it does the normal i-I-o-O path. Each outgoing packet hits i-I-o-O-o-O.

[Sky]

Thank you for the response, it seems there is still hope 😁

If I understood correctly what you meant is to make a rule with no explicit definition in the VPN column like below:

Source: Network defined in the route based VPN for the the first community 

Destination: Encryption Domain network/group defined in the policy based VPN of the second community 

VPN: -

Services: whatever is needed

Action: Accept

By doing so I should be able to se a "VPN Route" action on the logs, meaning that traffic will pass from one VPN Community (Route based) to the other one (Domain based).

I will try this configuration.

Thank you for the support so far.

[Bob_Zimmerman]

You shouldn't see "VPN Route" in the logs. That only shows up when you go from one remote peer's encryption domain to another remote peer's encryption domain. Since the firewall thinks the connection to your route-based peer is a really long ethernet cable rather than a domain-based VPN, it won't trigger that logic.

[IT_Eng]

OP, did you resolve that? We face the very same issue.

[Sky]

Yes I did. This was solved by upgrading the firewalls to r80.40 which supports the specific encryption domain for the community and placing there also the network used for source NAT towards the second domain based VPN.

Hope this will help you.