FTD: Port translation is not performed on outside2 interface

[Brunetta7]

Good morning everyone,

I am using a CSF 1210CE FTD and I need to publish a service so that it can be reached from two public IP addresses provided by different ISPs.
I configured a second external interface, created two static NATs with port translation (external 32500, internal 8080) one for each external interface and the relative access control rule.
The server is reachable from the first public IP address but not from the second.
From the syslog messages analysis it seems that the port translation is not performed on outside2 but only on outside1.
I checked and the NAT configuration is correct.
Can anyone help me?
Thanks
Have a nice day
Giuseppe

[MHM Cisco World]

First 

1- are you sure DNS return ISP2 public IP?

2- are you sure FTD dont use ISP1 for retrun traffic' try use packet tracer to check that.

MHM

[Brunetta7]

Thanks for the reply.
Users to connect remotely use the public IP address directly, not a domain name resolved by a DNS.
The remote user's request reaches outside2 correctly, the IP address of outside2 is reported in the syslog message. I don't think there are problems returning to isp1 because the packet is stopped before. To be clearer I'll post the syslog messages.
I hid the source IP with X.X.X.X

syslog message for connection from isp1,  it's ok
12:28:11 +ACU-FTD+AC0-6+AC0-302013: Built inbound TCP connection 277393 for outside:X.X.X.X/1724/1724 (X.X.X.X/1724) to inside:192.168.0.25/8080 (10.11.13.2/32500) 1 6
12:28:24 +ACU-FTD+AC0-6+AC0-302014: Teardown TCP connection 277393 for outside:X.X.X.X/1724 to inside:192.168.0.25/8080 duration 0:00:13 bytes 361335 TCP Reset+AC0-O from outside 1 6

syslog message for connection from isp2 ,  it's fail
12:28:27 +ACU-FTD+AC0-6+AC0-302013: Built inbound TCP connection 277416 for outside2:X.X.X.X/1548 (X.X.X.X/1548) to inside:192.168.0.25/32500 (192.168.178.2/32500) 1 6
12:28:27 +ACU-FTD+AC0-6+AC0-302014: Teardown TCP connection 277416 for outside2:X.X.X.X/1548 to inside:192.168.0.25/32500 duration 0:00:00 bytes 0 TCP Reset+AC0-O from inside 1 6

As you can see from the logs in the second case it seems that the port translation is not done

[MHM Cisco World]

Use packet-tracer to see in which phase the traffic is drop

MHM

[Brunetta7]

I am not very familiar with Packet-tracer.
I tried the following:
packet-tracer input outside2 t X.X.X.X 32500 192.168.0.25 8080 
The result is this:
.....
Phase: 6
Type: NAT
Subtype: rpf-check
Result: DROP
Elapsed time: 34816 ns
Config:
nat (inside,outside2) after-auto source static INTERNAL_SERVER ADDGRP_IPEsterni service _|NatOrigSvc_2d46bfc6-21f9-11f0-8111-efd80de64e46 _|NatMappedSvc_2d46bfc6-21f9-11f0-8111-efd80de64e46
Additional Information:

Result:
input-interface: outside2(vrfid:0)
input-status: up
input-line-status: up
output-interface: inside(vrfid:0)
output-status: up
output-line-status: up
Action: drop
Time Taken: 78848 ns
Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame snp_sp_handle_flow_drop:4208 flow (NA)/NA

[MHM Cisco World]

I need to see whole packet tracer 

MHM

[Brunetta7]

> packet-tracer input outside2 t X.X.X.X 32500 192.168.0.25 8080
Phase: 1
Type: ROUTE-LOOKUP
Subtype: No ECMP load balancing
Result: ALLOW
Elapsed time: 22528 ns
Config:
Additional Information:
Destination is locally connected. No ECMP load balancing.
Found next-hop 192.168.0.25 using egress ifc inside(vrfid:0)
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 5376 ns
Config:
access-group NGFW_ONBOX_ACL global
access-list NGFW_ONBOX_ACL advanced permit object-group |acSvcg-268435463 ifc outside2 object-group |acSrcNwg-268435463 ifc inside object IP_INTERNAL_SERVER rule-id 268435463 event-log both
access-list NGFW_ONBOX_ACL remark rule-id 268435463: ACCESS POLICY: NGFW_Access_Policy
access-list NGFW_ONBOX_ACL remark rule-id 268435463: L7 RULE: RULE3
object-group service |acSvcg-268435463
service-object tcp destination eq 8080
service-object tcp destination eq 32500
object-group network |acSrcNwg-268435463
group-object ADDGRP_IPEsterni
network-object object NOSTRIPPubblico2
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be reached
Phase: 3
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Elapsed time: 5376 ns
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection decrement-ttl
service-policy global_policy global
Additional Information:
Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 5376 ns
Config:
Additional Information:
Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 5376 ns
Config:
Additional Information:
Phase: 6
Type: NAT
Subtype: rpf-check
Result: DROP
Elapsed time: 34816 ns
Config:
nat (inside,outside2) after-auto source static IP_INTERNAL_SERVER ADDGRP_IPEsterni service _|NatOrigSvc_2d46bfc6-21f9-11f0-8111-efd80de64e46 _|NatMappedSvc_2d46bfc6-21f9-11f0-8111-efd80de64e46
Additional Information:
Result:
input-interface: outside2(vrfid:0)
input-status: up
input-line-status: up
output-interface: inside(vrfid:0)
output-status: up
output-line-status: up
Action: drop
Time Taken: 78848 ns
Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame snp_sp_handle_flow_drop:4208 flow (NA)/NA

[MHM Cisco World]

Edit

MHM

[Brunetta7]

I apologize but I did not understand the answer.
Obviously for privacy reasons I changed addresses and ports.
Inside my network I have a server with proprietary software that accepts connections from external users without VPN.
To balance the load of incoming connections, two public IP addresses are used.
The previous firewall worked like this, now I'm trying to replicate the same behavior on the CSF1210CE FTD,
is it possible?

Thanks

[MHM Cisco World · Accepted solution]

Sorry I confuse with other issue with anyconnect.

Anyway 

Rpf-check (drop) this cause because of asymmetric traffic.

Use packet-tracer but this time from inside to outside1/2

See if NAT is select correctly.

MHM

[Brunetta7]

Good morning everyone,
I finally managed to solve it, the problem was a trivial conflict with another nat policy.
After eliminating the unnecessary static nat, I managed to get my services working on both outside interfaces.
Thanks to MHM for your time.
Have a nice day
Giuseppe