bug? snat to wrong address?

[Ralph1973]

Hello,

I am struggling with a difficult setup that we want to implement with a customer. FortiOS 5.0.9

This is topology

Router -  Interf1(vlan3751)-Customer vdom-Interf2 -vdom link-  Application vdom

Traffic flows from Router to Application vdom

We want incoming traffic in Customer vdom to be snatted to 172.16.23.101 and destination natted from 157.52.35.207 to 100.65.16.72. This 100.65.x.x address resides in the Application vdom.

I've put the following rule in place in Customer vdom:

source interface Interf1

source ip any (because any ip can enter this)

dest. interface Interf2

dest ip: vip (157.52.35.207 -> 100.65.16.72)

service ANY

Nat: yes, ip pool 172.16.23.101-172.16.23.101

Now we ping with source ip 10.1.1.20 to 157.52.35.207 and we expect the traffic to be snatted and dnatted so that the packet enters the Application vdom with source address 172.23.1.101 and destination address 100.65.16.72

However, a debug shows this:

id=25956 trace_id=106 msg="vd-Cust-3751 received a packet(proto=1, 10.1.1.20:1->157.52.35.207:8) from vlan3751. code=8, type=0, id=1, seq=715." id=25956 trace_id=106 msg="allocate a new session-00005556" id=25956 trace_id=106 msg="[style="background-color: #ffff00;"]find SNAT: IP-100.65.16.72(from IPPOOL), port-1[/style]" id=25956 trace_id=106 msg="VIP-100.65.16.72:1, outdev-vlan3751" id=25956 trace_id=106 msg="DNAT 157.52.35.207:8->100.65.16.72:1" id=25956 trace_id=106 msg="[style="background-color: #ffff00;"]reverse path check fail, drop"[/style] id=25956 trace_id=106 msg="trace"

Strange thing is the line find SNAT, since I've put a rule to snat to ip 172.16.23.101, see attachment

Anybody knows what goes wrong here?

Please note that the 157.x.x.x address doesn't have an associated interface, but that shouldn't matter. The vdom can listen to it as long as you configure a vip for it , for example. The Interf1 also doesn't have an ip address, shouldn't be needed as well (I think)

Routing is set up.

Thank you and regards,

Ralph

[netmin]

Assuming Intf1 has the default route assigned, it seems there is a more specific (static) route missing on Intf2, i.e. to 100.65.16.72/32, so that the FGT knows where to route the traffic to. From the trace it looks like the FGT wants to send it back to Intf1.

[emnoc]

This is not a bug but probably your not understand how a VIP works,  the proper use of NAT and  this part really is confusing

"Nat: yes, ip pool 172.16.23.101-172.16.23.101"

So you have traffic entering with a a SRC of "any"  correct ?

You have a  vip in the customer-vdom correct ?

Next,  you have a route in customer vdom pointing to vip-mapped address { 100.65.16.72 } with this route pointed over the  vdom-link, like wise in the vdom application, you have a route pointing outbound over the same link?

Curious, if  you disable nat on the vip firewall policy, and move the ip pools to the application-vdom and install it on the  "inbound" policy of that virtual-firewall, I bet you this would work out fine. So on fwpolicy ( customer vdom ) you drop the nat and src-nat pool .

And

In application-vdom you perform your SNAT

srcintf -name of vdomlink

dstintf - name of where ever the application interface

srcaddr - any

dstaddr - 100.65.16.72

nat - enable

ip pool - "172.16.23.101-172.16.23.101"

Is that clear ?

[Ralph1973]

Hello Emnoc,

thank you for your advise. I moved the snat to the APP vdom, however same issues arise.

I have to find a way to get the traffic to travel passing the APP vdom manipulated and then reach the APPS environment. Please see drawing attached.

The Customer vdom has no ip addresses on its interfaces.

Interface (8) is in vlan 3751 and receives traffic from router. The traffic that enters is for example ip 10.1.1.20 , with destination 157.52.x.x

This traffic has to leave the APP vdom to APPS environment with source 172.23.1.101 and destination 100.65.16.x

When I move the dnat (from 157.52.x.x to 100.65.16.x) to the APP vdom, then the Customer vdom doesn't reply to (arp) packets for packets that enter Cust.vdom with dest.ip 157.52.x.x

So the Cust.vdom needs to listen to these addresses (though it doesn't have an interface(ip) in this subnet), then translate it to a 100.65.16.x address.

When I move the source natting from cust.vdom to APP vdom, the problem stays there. So now I configured:

On Cust. vdom: port 8 to the vlink with source all ; dest.interf vdom link, destination address: vip 157.52.35.207-> 100.65.16.72, service ANY

On APP vdom: source interf vdom link, source ip: all, dest.interface port 2(is the exit to the APP environment) dest. add 100.65.16.72. Nat enabled, ip pool 172.23.1.101-172.23.1.101

Routing in Cust vdom:

to 100.65.16.0 /24 via vdom link (to APP vdom)

default GW to 157.52.35.195 via interf.8 (which has no ip). Note that this address is in same range as where customer traffic connects to from outside cust.vdom into the cust.vdom.

Routing in App vdom:

route to 10.1.1.20 via vdom link (to Cust. vdom)

route to 100.65.16.0 /24 via port 2 (to apps environment)

this is what I receive:

id=0 trace_id=109 msg="vd-Cust-3751 received a packet(proto=1, 10.1.1.20:1->157.52.35.207:8) from vlan3751. code=8, type=0, id=1, seq=37392." id=0 trace_id=109 msg="allocate a new session-0002b55e" id=0 trace_id=109 msg="find SNAT: IP-100.65.16.72(from IPPOOL), port-1" id=0 trace_id=109 msg="VIP-100.65.16.72:1, outdev-vlan3751" id=0 trace_id=109 msg="DNAT 157.52.35.207:8->100.65.16.72:1" id=0 trace_id=109 msg="reverse path check fail, drop" id=0 trace_id=109 msg="trace"

What I find is strange is the SNAT ip 100.65.16.72 line, since I don't want to SNAT to this address and this address is only configured as DNAT address from the 157.52.x.x address

Is there a way that this can work, or do we have to assign addresses to e.g. port 8 to prevent that we receive reverse path failure messages?

Any help is appreciated!

Thanks,

Ralph

emnoc wrote:

This is not a bug but probably your not understand how a VIP works,  the proper use of NAT and  this part really is confusing

"Nat: yes, ip pool 172.16.23.101-172.16.23.101"

So you have traffic entering with a a SRC of "any"  correct ?

You have a  vip in the customer-vdom correct ?

Next,  you have a route in customer vdom pointing to vip-mapped address { 100.65.16.72 } with this route pointed over the  vdom-link, like wise in the vdom application, you have a route pointing outbound over the same link?

Curious, if  you disable nat on the vip firewall policy, and move the ip pools to the application-vdom and install it on the  "inbound" policy of that virtual-firewall, I bet you this would work out fine. So on fwpolicy ( customer vdom ) you drop the nat and src-nat pool .

And

In application-vdom you perform your SNAT

srcintf -name of vdomlink

dstintf - name of where ever the application interface

srcaddr - any

dstaddr - 100.65.16.72

nat - enable

ip pool - "172.16.23.101-172.16.23.101"

Is that clear ?

[Ralph1973]

Well, I have it working now. I assigned the customer vlan an ip address in the same subnet as the router and it appears that I can use ip addresses in the same address range of this subnet, on other vdoms, that is needed for the next customers.

Thanks ,

Ralph