vip fails, flow shows strange route

[journeyman]

We have two devices thing1 and thing2 on the dmz interface of a 60E. The devices are on different subnets. VIP access to thing1 is working fine, but thing2 fails with what looks like a routing issue that I can't sort out.

Relevant config:

config system interface
    edit "dmz"
        set vdom "root"
        set ip 10.6.6.1 255.255.255.248
        set secondary-IP enable
        config secondaryip
            edit 1
                set ip 192.168.91.2 255.255.255.224
            next
        end
    next
end
config firewall vip
    edit "vip-thing1"
        set extip 192.168.90.19
        set extintf "internal1"
        set mappedip "10.6.6.2"
    next
    edit "vip-thing2"
        set extip 192.168.90.21
        set extintf "internal1"
        set mappedip "192.168.21.24"
    next
end
config firewall policy
    edit 0
        set srcintf "internal1"
        set dstintf "dmz"
        set srcaddr "lan"
        set dstaddr "vip-thing1"
        set action accept
        set schedule "always"
        set service "RDP"
    next
    edit 0
        set srcintf "internal1"
        set dstintf "dmz"
        set srcaddr "lan"
        set dstaddr "vip-thing2"
        set action accept
        set schedule "always"
        set service "RDP"
    next
end

The trace for attempting to access thing2 looks like:

id=20085 trace_id=42 func=print_pkt_detail line=4793 msg="vd-root received a packet(proto=6, 192.168.90.12:53652->192.168.90.21:3389) from internal1. flag , seq 3920828874, ack 0, win 8192"
id=20085 trace_id=42 func=init_ip_session_common line=4944 msg="allocate a new session-2d106719"
id=20085 trace_id=42 func=fw_pre_route_handler line=182 msg="VIP-192.168.21.24:3389, outdev-internal1"
id=20085 trace_id=42 func=__ip_session_run_tuple line=2810 msg="DNAT 192.168.90.21:3389->192.168.21.24:3389"
id=20085 trace_id=42 func=vf_ip_route_input_common line=2586 msg="find a route: flag=00000000 gw-192.168.21.24 via root"

note the msg="find a route: flag=00000000 gw-192.168.21.24 via root"

the equivalent for thing1 (working) is:

msg="find a route: flag=04000000 gw-10.6.6.2 via dmz" The routing table looks like:

S       1.1.1.1/32 [10/0] via 192.168.90.1, internal1 # temporary change to the default route
C       10.6.6.0/29 is directly connected, dmz
C       192.168.90.0/26 is directly connected, internal1
C       192.168.91.0/27 is directly connected, dmz

Other info:

- thing1 and thing2 both have an ippool definition to match for rules in the other direction

What is indicated by either the route via root or the flag=00000000 vs flag=04000000?

Can anyone advise the next thing to check?

[lobstercreed · Accepted solution]

I think you have typoed the mappedip for thing2.  You need 91 in the 3rd octet, but you typed 21 instead.  This is consistent with the debug output as well.

[journeyman]

omg how embarrassing. Thank you for pointing that out, what I pity I didn't see it myself.

To get going we removed the config for thing2, redirected thing1 config to thing2 (correctly this time) and got in that way. the task was to re-address thing2 back onto the thing1 subnet and all ended well.

But would have been a whole lot faster without such a simple mistake.

Thanks again