SSH to Vdom Link IP Address

[velosy]

I have a Fortigate firewall with x2 VDOMs, root and user created called "management access".

root and management access have an inter-vdom link between them to exchange traffic and because of the requirements root is the "management vdom" and used as management access for us to manage our customers firewall. The problem I am facing is that you cant configure SNMP in a non "management vdom", so I have configured SNMP on the inter vdom link in root as a workaround which the management access vdom is directly connected to.

The problem is I cant seem to SSH onto the firewall using the intervdom link from our management jump box.

Does anyone know if its possible to SSH to a Fortigate on an intervdom link from outside the Fortigate firewall? I have checked routing+firewall policies but it does not appear to work.

[Toshi_Esumi]

vlinks/npu-vlinks are just another type of interface so you can allow admin access (SSH, HTTPS) to them. I just tested it with an npu-vlink and working file on my 40F.
Are you sure you have a policy where you're coming from to the vlink interface?

Toshi

[velosy]

Hi, Thanks for your quick response.

So I have a site to site VPN, that lands in my "Management access" VPN.  I have policy from the tunnel interface to the local inter vdom link allowing the traffic.

Because the root inter vdom link is on the edge, I should not need a policy there?

[Toshi_Esumi]

Are you trying to access on the opposite side of the vlink through root vdom? Then, do you have a return route in the customer vdom side for your source IP?

Toshi

[velosy]

Yes I am pinging/ssh the opposite vdom's, vdom link and I can see return traffic on the source vdom firewall logs, but the ping times out on the client.

[Toshi_Esumi]

If even ping doesn't work, it must be a routing issue on the customer vdom side.
Try sniff on the vlink interface on that vdom side like below. In below, "rt2tst1 is the npu-vlink interface on the test-vdom side as you can see in the promp. And 10.100.64.1/31 is the interface IP. I pinged it by coming through root vdom. If a proper route for the source IP (10.68.3.231), you should see the echo replies like below. I have a default route toward root vdom. You might need to filter out other traffic by specifying "icmp" and/or source IP to eliminate other noise.

fg40f-utm (test-vdom) # diag sniffer packet rt2tst1
interfaces=[rt2tst1]
filters=[none]
20.965328 arp who-has 10.100.64.1 tell 10.100.64.0
20.965375 arp reply 10.100.64.1 is-at 02:23:ff:22:d8:ff
20.965408 10.68.3.231 -> 10.100.64.1: icmp: echo request
20.965491 10.100.64.1 -> 10.68.3.231: icmp: echo reply
21.972809 10.68.3.231 -> 10.100.64.1: icmp: echo request
21.972852 10.100.64.1 -> 10.68.3.231: icmp: echo reply
22.989158 10.68.3.231 -> 10.100.64.1: icmp: echo request
22.989198 10.100.64.1 -> 10.68.3.231: icmp: echo reply
24.001544 10.68.3.231 -> 10.100.64.1: icmp: echo request
24.001592 10.100.64.1 -> 10.68.3.231: icmp: echo reply
25.969234 arp who-has 10.100.64.0 tell 10.100.64.1
25.969289 arp reply 10.100.64.0 is-at 02:23:ff:22:d8:fe

Toshi

[velosy]

I can see the ping reply and request on the customer vdom, but still timing out on the client.  x.x.x.9 being the vdom link ip and x.x.x.30 the client source address.

diag sniffer packet 11
interfaces=[11]
filters=[none]

7.517933 x.x.x.30 -> x.x.x.9: icmp: echo request
7.518029 x.x.x.9 -> x.x.x.30: icmp: echo reply

[Toshi_Esumi · Accepted solution]

Then routing at the vdom is fine. Now run sniffing at root vdom like below:
   diag snffer packet any 'host x.x.x.9 and icmp' 4
You should see packets passing through ingress and egress interfaces in root vdom. Likely the replis is lost in the root vdom.

Toshi

[velosy]

Thanks for your help, resolve this in the end. It was a downstream firewall.

[datorresv]

Hello

Enable SSH, SNMP, ping services. It should not be a problem and these should be functional.

Verify that routing on both vdoms is correct and validate that access rules are appropriate.

If possible, share an image of your current topology diagram to better understand the solution that is operating. Also include source and destination networks.

Cheers

Diego.