Hot!PAT via VIP occurring without policy match

Author
ad
New Member
  • Total Posts : 8
  • Scores: 0
  • Reward points: 0
  • Joined: 2019/12/10 19:26:30
  • Status: offline
2019/12/10 19:30:31 (permalink)
0

PAT via VIP occurring without policy match

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.
#1

4 Replies Related Threads

    lobstercreed
    Gold Member
    • Total Posts : 251
    • Scores: 32
    • Reward points: 0
    • Joined: 2018/11/28 14:57:58
    • Location: Sedalia, MO
    • Status: offline
    Re: PAT via VIP occurring without policy match 2019/12/10 20:27:15 (permalink)
    0
    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
    #2
    ad
    New Member
    • Total Posts : 8
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/12/10 19:26:30
    • Status: offline
    Re: PAT via VIP occurring without policy match 2019/12/10 22:34:23 (permalink)
    0
    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.
    #3
    rdumitrescu
    Bronze Member
    • Total Posts : 37
    • Scores: 11
    • Reward points: 0
    • Joined: 2014/12/02 08:06:13
    • Status: offline
    Re: PAT via VIP occurring without policy match 2019/12/11 01:02:00 (permalink)
    0
    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
    #4
    lobstercreed
    Gold Member
    • Total Posts : 251
    • Scores: 32
    • Reward points: 0
    • Joined: 2018/11/28 14:57:58
    • Location: Sedalia, MO
    • Status: offline
    Re: PAT via VIP occurring without policy match 2019/12/11 07:39:27 (permalink)
    0
    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.   :-) 
    #5
    Jump to:
    © 2020 APG vNext Commercial Version 5.5