Hi,
maybe someone has an idea, me not, anymore. :(
Setup
lan port 1, net 172.31.0.0/16 (NAT)
|
(site 1) Fortigate, WAN with public IP (fiber connected)
|
IPSEC site to site
|
(site 2) Fortigate, WAN with public IP (fiber connected)
|
lan port 1, net 10.20.20.0/24 (NAT)
Working / Details
- IPSEC is working fine without any bigger problem so far
- no additional modem / router is between, because of fiber-connection
- computer from site 1 from lan-segment can access computer on site 2 in lan-segment
- all policys to route networks 172.31.0.0/16 and 10.20.20.0/24 between the tunnels are setup by the wizard and working well
Non-Working
- Fortigate CLI on site 1 or site 2 is not able to ping Fortigate on other site, this is quite normal, because PING is disabled on this interface, however, Fortigate is not able to ping any computer in lan-segment on the other site
What I want to
- On site 1 I want to setup a public IP on my WAN interface, using one of the ip-addresses out of our public network, to setup a virtual server, or IP forwarder over NAT to access a computer on site 2. This is because of many IP addresses we have on site 1, but not on site 2. Normal virtual server or IP forwarder on site 1 is working, if destination is inside lan 1 (172.31.0.0/16). It does not work using a destination on site 2 from lan 10.20.20.0/24. Is this caused by the non-working-problem mentioned above? Or is it kind of routing problem, because site 2 is not knowing how to route back to source public ip from site 1?
Any help would be nice from you.
Best and thanks
Ronny
Two different issues. But you could have figured out when you used the same troubleshooting method: sniffing (diag debug sniffer packet ....)
1. when you pinged from FG-1 to Site-2-Device, it likely picked the tunnel (phase1) interface IP on FG-1 as its source IP, which you most unlikely specified in Phase2 traffic selector combinations. So ping must have reached Site-2-Device but FG-2 dropped the ping-reply.
2. Similar to No.1, I'm assuming the default route at FG-2 is not pointing into the tunnel to get to Site-1. The inbound packets coming through the DNAT you configured still has the same source public IP you're accessing from. It must have been reaching the Site-2-Device. But returning packets try going out toward the internet source via FG-2, which would be dropped there due to asymmetric routing.
I don't have a definitive solution if you can't change the default route at FG-2. Probably adding a SNAT in addition to DNAT to the policy would mitigate, but I haven't tried before. Somebody else might be able to chime in.
Again, you would see all of these when you sniff it at FG-2 and FG-1. Don't forget to disable asic-offloading at your policies if your FG model is equipped with asics. Otherwise, sniffing might not catch any packets through the encrypted tunnel.
toshiesumi wrote:
I don't have a definitive solution if you can't change the default route at FG-2. Probably adding a SNAT in addition to DNAT to the policy would mitigate, but I haven't tried before. Somebody else might be able to chime in.
Maybe a solution can be to route back from FG-2 to FG-1 using a route back to the public ip the VIP on FG-1 uses using a Route for the one ip only /32?
If only one source is using the access, that would do it. Don't forget to add it to IPsec phase2 selectors.
toshiesumi wrote:I did so, but, it does not work, either. It also can´t work I suppose. Public ip on FG-1 is connecting to wan1, forwarding to lan - IP on FG-2. Routing back to WAN-IP on FG-1 over VPN will fail I suppose, because, this IP is then not connected on VPN-interface, but still on WAN 1. So this fails, I suppose.If only one source is using the access, that would do it. Don't forget to add it to IPsec phase2 selectors.
We got it working. How to do it:
Set a NAT-Pool, set outgoing to the ip of the LAN - IP of LAN-Port 1 of Fortigate #1,
on the policy of the virtual IP or virtual server, enable NAT, and then, choose the pool from before,
so in this example, my Fortigate has 172.31.1.171 on site 1, so I had to set virtual NAT pool 172.31.1.171 outgoing, so route comes back, because, external public IP is then corrected to private internal one.
Works :)
No, the /32 static route at FG-2 is not routed to the outside IP of the WAN interface, it's routed into the tunnel or tunnel interface IP. You must have set the DNAT policy toward the tunnel interface. Have you actually sniffed them?
toshiesumi wrote:I got this working using NAT pool as mentioned above. Works fine :).No, the /32 static route at FG-2 is not routed to the outside IP of the WAN interface, it's routed into the tunnel or tunnel interface IP. You must have set the DNAT policy toward the tunnel interface. Have you actually sniffed them?
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 |
---|---|
1740 | |
1108 | |
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.