VDOM link not working

[support_swilson]

We have an old 80C unit with two vdoms for different subnets (10.0.0.0 and 10.1.0.0) and a VDOM link to connect the two. I've gone through setting up the VDOM link and have assigned an arbitrary address for each end (10.0.40.10/255.255.255.0 for 10.0.0.0 and 10.1.40.10/255.255.255.0 for 10.1.0.0).

The problem I'm seeing is that nothing is actually able to connect through the VDOM link for some reason. I'm by no means an expert on this so I may have something wrong. When I do a tracert from one side to the other I'm getting the to the firewall but it just dies on the link address. I can however ping the gateway address for the other subnet. (10.1.0.1 from the 10.0.0.0 subnet for example).

Any ideas? Really hoping I'm just missing something simple.

[Carl_Wallmark]

Hi,

Have you checked that routing is correct on "the other side" ?

Also policies ?

For example:

You are on network 192.168.1.0/24 and want to ping 172.16.16.100 (on the other side)

You need a route on both VDOMs:

172.16.16.0/24 -> VDOM Link2

192.168.1.0/24 -> VDOM Link1

[support_swilson]

Thanks for the reply. I should have mentioned that I do have static routes in place on both VDOMs directing traffic for the appropriate subnets through the VDOM link interfaces.

Policies are also in place and since it's just internal I have them wide open (ALL/ACCEPT) for testing purposes.

[MrSinners]

The best would be to run a debug flow trace to see what the Fortigate is doing with the traffic on each VDOM and most likely shows a reason if the traffic stops somewhere. Are both IP addresses on the VDOM links in the same network? Are they 10.1.40.0/24 and 10.0.40/24? If so then they are not on the same network and that should be corrected. Do you know how to run a debug flow trace?

[support_swilson]

So I just corrected the VDOM Link addresses as you suggested. I'm using 10.0.40.10 and 10.0.40.11 instead of having them on different subnets.

I found this article on debug flow which was helpful.

http://kb.fortinet.com/kb/documentLink.do?externalID=FD33882

When I run the trace from the VDOM for 10.0.0.0 for an address on the 10.1.0.0 subnet (10.1.0.23) I'm seeing this. 

2016-09-07 08:56:56 id=20085 trace_id=84 func=ip_session_run_all_tuple line=5648 msg="SNAT 10.0.1.40->10.1.0.1:62464" 2016-09-07 08:56:59 id=20085 trace_id=85 func=print_pkt_detail line=4478 msg="vd-root received a packet(proto=1, 10.0.1.40:1->10.1.0.23:8) from internal1. code=8, type=0, id=1, seq=5438." 2016-09-07 08:56:59 id=20085 trace_id=85 func=resolve_ip_tuple_fast line=4539 msg="Find an existing session, id-00ac3154, original direction" 2016-09-07 08:56:59 id=20085 trace_id=85 func=ipv4_fast_cb line=50 msg="enter fast path" 2016-09-07 08:56:59 id=20085 trace_id=86 func=print_pkt_detail line=4478 msg="vd-VM-Storage received a packet(proto=1, 10.0.1.40:1->10.1.0.23:8) from root-VM-Str1. code=8, type=0, id=1, seq=5438." 2016-09-07 08:56:59 id=20085 trace_id=86 func=resolve_ip_tuple_fast line=4539 msg="Find an existing session, id-00ac3155, original direction" 2016-09-07 08:56:59 id=20085 trace_id=86 func=ipv4_fast_cb line=50 msg="enter fast path"

This is the first I've done a trace but it looks like it is picking up the PING I'm doing across the VDOM link. Thanks again for the help with this.

[MrSinners]

Yes, the ping packet arrives on both VDOM's and both allow it. It looks like VDOM root is doing source NAT from the 10.0.0.0 subnet to 10.0.1.40, the VDOM link. Normally this is not required on the internal side of the network unless you have overlapping subnets. This means policies on VDOM VM-Storage cannot use policies containing the 10.0.0.0 subnet as source, unless Source NAT is turned of on VDOM root.

[support_swilson]

Turns out the managed switch we were using had a few random ports that were completely turned off. One of the ports was the one I was using as the uplink to the Foritigate unit.

Thanks for all the help, I'll remember to check back in with this community in the future.