Route gateway initiated traffic over a VPN?

[LukeOxley]

Hi,

Can gateway initiated traffic be routed over a VPN? For context, we have a gateway that needs to send RADIUS authentication requests for OfficeMode authentication across one of its VPNs to a domain controller in Azure (remote enc dom), however I've marked an issue with the design of this as I know that gateway initiated traffic by default WILL NOT route over a VPN.

I've tried it in a lab environment and can see that gateway initiated traffic tries to leave the gateway's external interface unencrypted (with the source address being the gateway's public address) to the domain controller's IP (that is in the remote enc dom) and is then dropped:

;[cpu_0];[fw4_0];fw_log_drop_ex: Packet proto=1 194.75.238.218:2048 -> 10.0.0.5:30712 dropped by vpn_encrypt_chain Reason: No error;

Any ideas here or have you had a similar requirement before?

[Bob_Zimmerman]

That should definitely be possible and should work by default. The "Set permanent tunnels" option in a VPN community actually sets the firewall to send probe traffic to the peers in the community, which gets flagged as interesting by default, which triggers negotiations as a side-effect.

How do you have the firewall's encryption domain defined?

Are you using VSX to separate to-traffic from through-traffic, or do you only have one routing table?

[Maarten_Sjouw · Accepted solution]

I ran into this issue when I was using AD authentication with remote gateways, the AD traffic was not encrypted either due to a implied rule that says the traffic should not be encrypted.
Check out this SK:
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[LukeOxley · Accepted solution]

Hi @Maarten_Sjouw,

Thanks for the reply. You're right with sk31692, I found that you could use implied_rules.def to force all sorts of gateway initiated traffic over the VPN. however, I actually used route based VPNs to achieve this...

...No matter how I went about it initially, there was no configuration that would cause the packet to get encrypted, and I think this is due to where gateway initiated traffic starts in the chain, it doesn’t enter from the start of the inbound chain like a normal traversal packet would.

At the early stages of the inbound chain a flag (or similar) must get attached to the packet to mark it for encryption so that when it reaches the end of the outbound chain it gets encrypted (at least, this is how it works in other firewall vendors, and the behavior seems similar based on what I’m seeing). However, this was not taking place due to the position gateway initiated packets enter the chain, thus not getting marked for encryption (or something like that).

Converting the tunnel to route based VPN worked perfectly as I thought. This pushes the packet via the VT interface which seems to apply all of the needed chain elements you’d get from a normal traversal packet (potentially full inbound chain, full outbound chain, but I haven’t checked on a kernel debug) thus it gets marked for encryption, encrypted, and sent out correctly - you can even use NAT to manipulate the source address it is sent with, if needs be. By default if using numbered VTIs it uses the “local” address on the VTI as the source and if using unnumbered VTIs it seems to use the gateway main IP as the source.

Either way - all sorted! Thanks for the reply.