Connecting to a server behind two firewalls and 1 VPN

[Marc0523]

We are moving all of the servers in an office to a DC.

Our plan is for customers to connect to the current public IP, and have their traffic pushed down a VPN tunnel to the DC. The office will get a new IP range, and the DC will use the old range, meaning as little as possible needs to be reconfigured.

The two pairs of FortiGate firewalls are configured with a VPN tunnel between them. From the office, you can get full access to the test server in the DC. The issue is trying to connect to the test server from a public IP via the office, IE simulating what our customers will do. For some unknown reason, the firewall in the office will not push the traffic to the DC.

I have configured a virtual IP in the office with a public IP and the test servers IP, so it shouldn't be a routing issue.

There is no need for NAT inside our network as all devices are on different IP ranges.

Again, from the office to the DC works, so it isn't an obvious tunnel error.

Ping Fails

End user's laptop	Public IP	->	Firewall (100F)	->	VPN	->	Firewall (200F)	->	Test server
4.3.2.1	1.2.3.4		10.19.0.0		.19 <-> .26		10.26.0.0		10.26.0.10

Ping Works!

Office PC	->	Firewall (100F)	->	VPN	->	Firewall (200F)	->	Test server
10.19.1.2		10.19.0.0		.19 <-> .26		10.26.0.0		10.26.0.10

 

Why doesn't the ping get through?
What have I configured incorrectly?

What logs should I have included with this post?

[ebilcari]

Maybe I got it wrong, but the VIP usually is configured with a TCP or a UDP port not ICMP.

A firewall policy for the port fwd need to be created and should include the WAN (in) and the LAN (out, in this case the VPN interface) where this server is reachable and use the VIP object as the destination.
If you are not using NAT on this policy than the server should route the response for the public network back to 100F. Check if the 2nd firewall is allowing this requests and is doing routing correctly

[Marc0523]

---

@ebilcari wrote:

Maybe I got it wrong, but the VIP usually is configured with a TCP or a UDP port not ICMP.

A firewall policy for the port fwd need to be created and should include the WAN (in) and the LAN (out, in this case the VPN interface) where this server is reachable and use the VIP object as the destination.
If you are not using NAT on this policy than the server should route the response for the public network back to 100F. Check if the 2nd firewall is allowing this requests and is doing routing correctly

---

How did I miss this!

Thanks.

Pings appear to travel through the first firewall, but they are getting blocked at the tunnel.

Flow Debug helped me find the error location.

id=20085 trace_id=4 func=print_pkt_detail line=5822 msg="vd-root:0 received a packet(proto=1, 4.3.2.1:57378->1.2.3.4:2048) from wan1. type=8, code=0, id=57378, seq=305."
id=20085 trace_id=4 func=resolve_ip_tuple_fast line=5903 msg="Find an existing session, id-00ebe71a, original direction"
id=20085 trace_id=4 func=__ip_session_run_tuple line=3531 msg="DNAT 1.2.3.4:8->10.26.0.10:57378"
id=20085 trace_id=4 func=npu_handle_session44 line=1217 msg="Trying to offloading session from wan1 to Tunnel, skb.npu_flag=00000400 ses.state=00004204 ses.npu_state=0x01040000"
id=20085 trace_id=4 func=fw_forward_dirty_handler line=397 msg="state=00004204, state2=00000001, npu_state=01040000"
id=20085 trace_id=4 func=ipd_post_route_handler line=490 msg="out Tunnel vwl_zone_id 0, state2 0x1, quality 0.
"
id=20085 trace_id=4 func=ipsecdev_hard_start_xmit line=790 msg="enter IPsec interface-Tunnel"
id=20085 trace_id=4 func=_ipsecdev_hard_start_xmit line=667 msg="IPsec tunnel-Tunnel"
id=20085 trace_id=4 func=ipsec_common_output4 line=875 msg="No matching IPsec selector, drop"

It looks like the tunnel isn't accepting the traffic, because it's destination IP (1.2.3.4) isn't a destination for the tunnel?

Phase 2 config is this: 

Name	Local Address	Remote Address
Tunnel	10.19.0.0/16	10.26.0.0/16

Any idea on how I fix this second issue?

[ebilcari]

Did you try to enable NAT on the firewall policy that allow the access? In this way the request will be SNAT with the IP of the VPN tunnel so there is no need to add routes or include the subnet in the VPN.

The drawback is that all requests coming to the server will be sourced by the same IP of the FGT but in most cases this doesn't cause any issue.

[Toshi_Esumi]

Most likely because the DC's default route is not coming back over the tunnel. If you sniff or flow-debug on the DC FGT 200F, you can see the access is coming in via the VIP but dropped at the 200F due to "reverse path check, fail". You could try SNAT on the VIP policy.

But by considering the final arrangement, I would force all customers using DNS names instead of the public IPs first. Then when you move one server, you can change the IP to a DC native one at the DNS server. Otherwise, eventually all customers need to change the IPs to access to the servers to the DC native ones.

Toshi

[Marc0523]

Thanks for the reply.

I think return traffic will cause me another headache, but currently the pings are not hitting the server, so that a problem for future me.

As for using DNS names instead... this would be lovely, but the decision is not mine to make.

[Toshi_Esumi]

I overlooked your debug result. Of course the ping packets from 4.3.2.1 would be dropped because source IP range in phase2 selector is 10.19.0.0/16. You have to ping from this subnet.

Toshi