- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
I had an interesting discussion with @MPI-AE a few weeks ago that seems to reflect a recurring question, as I received similar questions from different sources in the meanwhile. So I thought I'd try to highlight some nuances and concepts that may not always be clear.
Configuring a VPN tunnel requires the creation of an IKE Gateway and IPSec tunnel that need to be bound to an interface, and then there's also a tunnel interface.
So which interfaces (physical or virtual) come into play and at which stage of the whole process?
To start, it is important to understand that the IPSec tunnel has a physical and virtual aspect: at the physical layer it is a communication between two devices, typically firewalls. It is best to consider this communication as nothing more than a point-to-point connection when considering which zones to use and to which interface to bind your IKE gateway: you need to establish a session from your firewall over the internet to a remote peer, so usually the best interface is the one closest to the peer, which is the external interface (typically 'untrust').
In some cases, for example, when there is a secondary external IP range in play or a different IP than the one bound to the external interface needs to be used, a loopback interface can be used instead of the physical interface.
This is the first hurdle: It's recommended to have the loopback interface be in the same zone as the external interface as this makes for the most seamless deployment. Routing is already in place, security policy is simple as one can rely on the default intrazone rules and no NATing is required.
There is a use case (see link at the bottom) where the loopback can be in a different zone, and this is when the loopback is in an internal subnet (eg. 10.0.0.1) and NAT needs to be applied. This does bring additional complexity as additional security policies need to be created and IPSec needs to be made to support NAT traversal, so beware when deploying this type of scenario.
The second hurdle is the tunnel interface: notice I haven't mentioned this type of interface yet. This is because it belongs to the second layer of the bigger picture.
After the IPSec communication (between firewalls) has been established, a tunnel is created which terminates on a tunnel interface that facilitates communication between clients and servers. This tunnel interface should be considered in the same way a physical interface would, and the IPSec session is the cable. The tunnel interface needs to be added to the Virtual Router, and to enable clients from reaching out to remote servers, routes or PBF rules need to be added to allow packets to be sent into the tunnel, just like a regular interface.
This is why it is recommended to set the tunnel interface in a different zone than the other interfaces, so security policies can also be created like you would between LAN and DMZ.
The original discussion is here.
A similar discussion with loopback in a different zone and NAT was already featured here.
A good resource to help set up a VPN tunnel can be found here.
I hope this was useful!
Reaper out!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Subject | Likes |
---|---|
2 Likes | |
1 Like | |
1 Like | |
1 Like | |
1 Like |
User | Likes Count |
---|---|
3 | |
3 | |
2 | |
1 | |
1 |