PAT via VIP occurring without policy match

[ad]

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]

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-in...), 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

[ad]

Thanks Daniel. The concept of "owning" the ip makes sense and a colleague and I were speculating that might be how fortios is working. I tried configuring a new VIP as you suggest (see below) and using it for the dstaddr in policy 1, but it didnt help. 

edit "vip-10.0.49.1-tcp22" 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 22 next

The debug message was pretty much identical to before, so it looks like the VIP that was created first still owns the IP. FWIW it looks like other flows to 10.0.49.1 were working, but i'll need to confirm that with the server team.

[rdumitrescu]

Hi,

I think a solution can be to set a source filter in the VIP configuration

edit "vip-10.0.49.1-tcp22"

set src-filter 2.2.2.2

next

[lobstercreed]

Yeah, I guess it goes back to the fact that destination NAT happens first.  If I get a packet destined for a VIP on a given port, I need to translate it before I can determine where to send it (routing) and only then can I figure out whether it is allowed by policy (source IP comparison).

Seems the only workaround is to set that src-filter attribute.  It does allow multiple entries including subnets and ranges, so it seems like you'll just need to update that field with any addresses you use in policy 2.  (Use command append src-filter <address> to add more to the existing list.)

Or you could just configure whatever system is supposed to access port 2222 to *actually* access port 2222....but ya know.   :)