SSL VPN one way traffic

[bbeverag]

I have a fortigate with multiple VDOMs.  We have SSL VPN working on two of them, and I am trying to stand it up on a third without much luck.  I can connect to the SSL VPN with my forticlient, but traffic is only one way once connected.  For instance, if I ping a host inside my network, I can see the echo request leave the fortigate on the LAN interface, hit the host, the host responds, I see the packet hit my LAN interface, and then it just falls into the ether.  Here is a debug:

id=20085 trace_id=101 func=print_pkt_detail line=5304 msg="vd-my received a packet(proto=1, 10.254.252.1:1->10.1.251.1:2048) from ssl.my-public. type=8, code=0, id=1, seq=103." id=20085 trace_id=101 func=init_ip_session_common line=5463 msg="allocate a new session-6cd0a158" id=20085 trace_id=101 func=vf_ip4_route_input line=1599 msg="find a route: flags=00000000 gw-10.4.251.1 via public-lan" id=20085 trace_id=101 func=fw_forward_handler line=737 msg="Allowed by Policy-1:" id=20085 trace_id=102 func=print_pkt_detail line=5304 msg="vd-my received a packet(proto=1, 10.1.251.1:1->10.254.252.1:0) from public-lan. type=0, code=0, id=1, seq=103." id=20085 trace_id=102 func=resolve_ip_tuple_fast line=5379 msg="Find an existing session, id-6cd0a158, reply direction" id=20085 trace_id=102 func=vf_ip4_route_input line=1599 msg="find a route: flags=80000000 gw-10.254.252.1 via my-public"

VDOM name: my

WAN: my-public

LAN: public-lan

SSL VPN is ssl.my-public

Here are captures of the LAN interface and the SSL VPN interface, same ping.

# diagnose sniffer packet public-lan 'host 10.1.251.1' interfaces=[public-lan] filters=[host 10.1.251.1] 4.855771 10.254.252.1 -> 10.1.251.1: icmp: echo request 4.858110 10.1.251.1 -> 10.254.252.1: icmp: echo reply 9.640485 10.254.252.1 -> 10.1.251.1: icmp: echo request 9.640846 10.1.251.1 -> 10.254.252.1: icmp: echo reply 14.643228 10.254.252.1 -> 10.1.251.1: icmp: echo request 14.643548 10.1.251.1 -> 10.254.252.1: icmp: echo reply 19.646006 10.254.252.1 -> 10.1.251.1: icmp: echo request 19.646387 10.1.251.1 -> 10.254.252.1: icmp: echo reply

8 packets received by filter 0 packets dropped by kernel

# diagnose sniffer packet ssl.my-public 'host 10.1.251.1' interfaces=[ssl.my-public] filters=[host 10.1.251.1] pcap_lookupnet: ssl.my-public: no IPv4 address assigned 6.169940 10.254.252.1 -> 10.1.251.1: icmp: echo request 11.157640 10.254.252.1 -> 10.1.251.1: icmp: echo request 16.159604 10.254.252.1 -> 10.1.251.1: icmp: echo request 21.163436 10.254.252.1 -> 10.1.251.1: icmp: echo request

I have temporarily created a static route on the next hop router to get 10.254.252.0/24 back to this VDOM, and that is working for my tests.  The only static route I have on my VDOM is a default route to the internet.  The rest of the routes are learned via OSPF.  I also tried enabling NAT on my SSL VPN -> LAN policy but I see the same behavior -- the fortigate seems to simply not know how to send the packets back to 10.254.252.1 once it receives them.  

I am certain i missed something simple, but I have gone through a few guides to double check my steps and have been unsuccessful in finding anything I am missing.

[Toshi_Esumi]

Is 10.254.252.1 the IP assigned to the client? Or the interface IP you configured on ssl.my-public? I'm assuming the former though.

Then the next question is do you actually see a route for 10.254.252.0/24 in the routing-table? In the gui or cli (get router info routing-table all). I assume it's not there. If so, a static route for the /24 to ssl.my-public would probably fix it.

[bbeverag]

It turns out it was something simple.  When initially doing the setup, I configured a NAT pool with the same IP range by mistake.  As soon as I removed it, everything starting working as expected.

[Toshi_Esumi]

Next time you allocate a subnet at the FGT, check the current routing-table first before configuring it. We make that as a habit every time we do the same at any L3 devices and check at least at one device on the same network (the rest is sharing the same via routing protocols).