Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Adrien
New Contributor

VdomA over VdomB : error with fortinet subnets (173.243.138) only

Dear all,

I have a strange issue since 6.2 release (not 100% sure but probably when i've updated from 6.0.x to 6.2.5) My configuration is: A Vdom "company" with all my internal VLANs and DMZ. A Vdom "root" with only one physical interface (port11): a private IP (10.63.32.14), used to connect to my metropolitan network provider (10.63.32.13). It is my global uplink, and this private IP is just used to interconnect the two devices (not routed /30 subnet)

 

All "company" VDOM traffic is sent to "root" VDOM, then go through internet over the root physical interface called "WAN", without NAT, using VDOMlink. All this trafic arrived with public IP (NAT private IP are done inside company vdom).

 

Since this upgrade, i have this strange behaviour. All work as before, but ONLY IP to 173.243.138.x (fortinet subnets) "bypass" all my NAT and VDOM rules. Only for this subnet, Source IP is ALWAYS my private WAN IP.... Don't know why. Even if my source is located in DMZ of vdom "company", next hop router will always see my private IP of vdom root wan interface...

 

There is no allusion to 173.243.138 in my config file.

Exemple of ping from DMZ IP (vdom company, IP 193.49.98.10 ) to Fortinet IP 173.243.138.108,

diagnose on vdom root:

2021-01-18 15:55:53 id=20085 trace_id=1144 func=print_pkt_detail line=5607 msg="vd-Arbois:0 received a packet(proto=1, 193.49.98.10:25119->173.243.138.108:2048) from DMZ. type=8, code=0, id=25119, seq=6821."

2021-01-18 15:55:53 id=20085 trace_id=1144 func=resolve_ip_tuple_fast line=5687 msg="Find an existing session, id-17bc13b3, original direction"

2021-01-18 15:55:53 id=20085 trace_id=1144 func=ipv4_fast_cb line=53 msg="enter fast path"

2021-01-18 15:55:53 id=20085 trace_id=1144 func=ip_session_run_all_tuple line=6882 msg="SNAT 193.49.98.10->169.254.20.1:25119"

diagnose on vdom Company

2021-01-18 15:58:11 id=20085 trace_id=1691 func=print_pkt_detail line=5607 msg="vd-root:0 received a packet(proto=1, 169.254.20.1:25119->173.243.138.108:2048) from Vdom_RAIMU1. type=8, code=0, id=25119, seq=6956."

2021-01-18 15:58:11 id=20085 trace_id=1691 func=init_ip_session_common line=5777 msg="allocate a new session-17ccea8e"

2021-01-18 15:58:11 id=20085 trace_id=1691 func=vf_ip_route_input_common line=2595 msg="find a route: flag=04000000 gw-10.63.32.13 via port11"

2021-01-18 15:58:11 id=20085 trace_id=1691 func=fw_forward_handler line=664 msg="Denied by source check, drop"

 

No idea how to proceed, can you please give me some ideas? My users can't install fortinet app when they are inside my lan... :(

 

PS: I use this "root" vdom for historical reasons. Because my WAN interface is a private IP, this vdom allow me to perform firewall updates. (Long story with fortinet support few years ago, solved by this). 

2 REPLIES 2
emnoc
Esteemed Contributor III

The error is in the diag debug { "Denied by source check, drop" }  and are you seriously using  APIPIA address, or did you do that to anonymize the diag debug flow output ?

 

I would check my routing.

 

Ken Felix

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Adrien
New Contributor

Hi Emnoc, Thank you for your quick reply. Yes APIPIA address are used, don't know why, i'll change that. About diag debug { "Denied by source check, drop" }, that's what i'm looking for. And yes, i'm checking routing actually! Regards,

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors