We have a number of site-to-site interface-based VPNs with various clients and locations and some 3rd parties.
We had one 3rd party recently ask us to mesh all traffic through a single tunnel for all sites that need the access because they were unwilling to create tunnels to the other sites. The traffic for this tunnel is NATted and not NATted, depending on destination. The NAT is done through an IP Pool of 172.16.16.0/22 where the pool is using 172.16.16.1-172.16.18.254. I've purposely left the rest of the pool out so we can do static NATs through the IP Pool (might not be the best option, but best option I found for this). The purpose of the NAT is to get some users into an SAP environment and the 172.16.19.* I've reserved individually for SAP printers. This works flawlessly, so far.
Up until today all traffic was being initiated from the sites to the 3rd party and they were using local SAP printing. Now we have a requirement that for some of the printers that the 3rd party be able to initiate the VPN traffic.
The way I've accomplished this is 1-to-1 VIP with source of NAT and destination of the sites in question. The firewall policy then takes the traffic from the SAP environment and moves the traffic along (I've just done this) and routing puts it to the right firewall/location.
In theory, I think this will work but it doesn't seem to. That said, the 3rd party is also not usually great when it comes to their firewalls....so they could just as easily have screwed something up too.
Have I overlooked anything, is there a less complicated way I've missed to do this?
It's ugly, but luckily only supposed to be around for the next 6 months or so (famous last words).
Thanks,
Brent
So this looks like it would take some routing.
Question - is the IP you are needing to reach at that vendor IP in use anywhere else?
If the answer is no, then I would include that IP in your other ipsec tunnels that need to reach the SAP vendor in question. Since you would already have static routes pointing to each vpn tunnel, traffic for the IP (172.16.19.*) should eventually egress off the one Firewall with the site2site to the SAP vendor.
I hope that made sense
I actually figured this out about a day after I sent the post.
It was in fact routing back to the primary firewall outside the mesh that I had messed up. I needed a Quick Mode selector for the traffic.
I had the VIPs right and the outgoing traffic fine. Also - I had the 3rd party send me the traffic through an existing NAT we had with them. Once I saw the traffic hitting the edge firewall it was easy enough to get the rest working.
Thanks!
A cool method and we did the same with a local VIP in the central FQ that had site-site vpn. In fact we deploy a VIP for each spoke to route to the vendor lan over the single tunnel.
PCNSE
NSE
StrongSwan
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1737 | |
1107 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.