PAT via VIP occurring without policy match

Question

Fortigate 5.4.5 needs to PAT (or not) based on source IP address.

host-1.1.1.1 needs to connect to 10.0.49.1 port 22 and be pushed through as is to 10.0.49.1 port 22 host-2.2.2.2 needs to connect to 10.0.49.1 port 22 but be PATed so that the connection forwards to 10.0.49.1 port 2222

So we have; config firewall policy edit 1 set srcintf "any" set dstintf "any" set srcaddr "host-1.1.1.1" set dstaddr "h-10.0.49.1" set action accept set service "ssh" set logtraffic all next edit 2 set srcintf "any" set dstintf "any" set srcaddr "host-2.2.2.2" set dstaddr "vip-10.0.49.1-tcp2222" set action accept set service "tcp2222" set logtraffic all next

and the vip is config firewall vip edit "vip-10.0.49.1-tcp2222" set extip 10.0.49.1 set extintf "any" set arp-reply disable set portforward enable set mappedip "10.0.49.1" set extport 22 set mappedport 2222 next

With this configuration, when h-1.1.1.1 attempts its connect to 10.0.49.1, it fails;

id=20085 trace_id=4 func=print_pkt_detail line=4903 msg="vd-blah received a packet(proto=6, 1.1.1.1:45721->10.120.49.1:22) from port11-97. flag , seq 3745010954, ack 0, win 5840" id=20085 trace_id=4 func=init_ip_session_common line=5047 msg="allocate a new session-002bac70" id=20085 trace_id=4 func=fw_pre_route_handler line=182 msg="VIP-10.0.49.1:2222, outdev-unkown" id=20085 trace_id=4 func=__ip_session_run_tuple line=2894 msg="DNAT 10.0.49.1:22->10.0.49.1:2222" id=20085 trace_id=4 func=vf_ip_route_input_common line=2583 msg="find a route: flag=04000000 gw-10.0.49.1 via port11-2105" id=20085 trace_id=4 func=fw_forward_handler line=577 msg="Denied by forward policy check (policy 0)"

Coming from a checkpoint background, I expected that the connection attempt would be processed by policy 1 and passed through as is. Can anyone explain what's happening here?

I can get this to work by adding "set src-filter 2.2.2.2" to the VIP, but that seems hacky and will be difficult in the real world (there will be many entries, and its opaque) operationally.

lobstercreed · Answer

Hi Adam,

Wow, this makes my head hurt. I've never heard of a non-NAT port forward, ha. Thinking about how the firewall processes packets (see here: https://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-life-of-packet-54/lop-packet-flow-ingress-egress.htm), Destination NAT happens before any routing or policies, so I think that's your why. I'm initially inclined to think there's no way around it, but I think there may be. You need to create another VIP for traffic from 1.1.1.1 instead of using a normal address object. "forward" port 22 to port 22 (why not, since you're forwarding the same IP to the same IP, ha) and see if that solves the issue.

Basically once you create a VIP, that object "owns" the IP address in the firewall unless you have more than one with different port forwarding. I actually ran into this when I was trying to prep for an IP change on a server and created the VIP for it's old (current) IP ahead of time. No policies were even pointing at it yet, but all of a sudden all traffic to the server was dropped. I deleted the object and was back in business.

Hope this helps! - Daniel

Sign up

Login with SSO

Login to the community

Login with SSO