Hi Prapanch and Kevin

Both of your input helped me to get closer to the solution, whereas I've learned some lessons from your input, Kevin. I've learned, that it's required to also add a NAT statement for returning traffic, if the returning traffic is coming from a higher-level security interface. So my configured outside NAT is not enough to achieve bidirectional translation, right?

Thanks also for reminding me to turn of 'names' for troubleshooting purposes. Sorry for that, yet I'll continue to use the names in the ACLs, it's easier for me to organize all the config sniplets I've accumulated so far.

Now I've configured the following lines for return traffic (and I noticed I have to do the matching on the real IPs 192.168.44.0 /24 (= 'vpn-clients') and not 10.25.125.9 /32, otherwise the asymmetric translation errors won't go away):

access-list nonat-Swisscom extended permit ip object-group Swisscom_gin vpn-clients 255.255.255.0

nat (Swisscom) 0 access-list nonat-Swisscom

Also, I've made sure the ACL in the return path will allow the traffic towards the VPN clients:

access-list Swisscom_access_in extended permit ip object-group Swisscom_gin host 10.25.125.9
access-list Swisscom_access_in extended permit ip object-group Swisscom_gin vpn-clients 255.255.255.0

Now the asymmetric translation error has gone away, yet there's still no traffic flowing. I've done a packet-trace with the following options:

packet-tracer input Swisscom tcp 10.237.214.151 21 192.168.44.3 3321 detail

And this is where the packet gets stuck...something seems very fishy here:

Phase: 10
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
nat (outside) 4 access-list vpn_nat_Swisscom outside
nat-control
  match ip outside vpn-clients 255.255.255.0 Swisscom host 10.237.214.151
    dynamic translation to pool 4 (10.25.125.9)
    translate_hits = 33, untranslate_hits = 0
Additional Information:
Forward Flow based lookup yields rule:
out id=0xd7c8f368, priority=2, domain=nat-reverse, deny=false
        hits=1, user_data=0xd7c8f210, cs_id=0x0, flags=0x0, protocol=0
        src ip=10.237.214.151, mask=255.255.255.255, port=0
        dst ip=vpn-clients, mask=255.255.255.0, port=0, dscp=0x0

I've also temporarily disabled 'ip verify reverse-path interface Swisscom', no success.

What could be wrong this time?

Toni

Hey,

The issue i think is because you have now configured the NAT exemption using the nat (Swisscom) 0  access-list nonat-Swisscom

This basically says there is not going to be any NAT involved for traffic from the 10.237.214.151 server to the VPN clients and vice versa. But in fact, you want to PAT the VPN client IP addresses. Instead of having a nat exemption, please try adding the below:

static (Swisscom,outside) Swisscom_gin access-list nonat-Swisscom

You can choose to change the name of the access-list to be more relevant. This does almost the same thing as NAT exemption. Let me know if this helps.

Another option you have is to remove the NAT exemption and disable "nat-control".

Regards,

Prapanch

Hey just realized that if you use the static command it is going to give you an error.

So, here is the command you will need.

access-list Swisscom-VPN permit ip host 10.237.214.151 vpn-clients  255.255.255.0

static (Swisscom,outside) 10.237.214.151 access-list Swisscom-VPN

try adding this instead of the NAT exemptions and see if it helps.

Regards,

Prapanch

Hi Prapanch

Thanks for your input. So I've removed the nat (Swisscom) 0 access-list nonat-Swisscom and added the static with an ACL as you've proposed.

No success either. This is what packet-tracer tells me now:

Phase: 9
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
nat (outside) 4 access-list vpn_nat_Swisscom outside
nat-control
  match ip outside vpn-clients 255.255.255.0 Swisscom host 10.237.214.151
    dynamic translation to pool 4 (10.25.125.9)
    translate_hits = 40, untranslate_hits = 0
Additional Information:
Forward Flow based lookup yields rule:
out id=0xd7c8f368, priority=2, domain=nat-reverse, deny=false
        hits=2, user_data=0xd7c8f210, cs_id=0x0, flags=0x0, protocol=0
        src ip=10.237.214.151, mask=255.255.255.255, port=0
        dst ip=vpn-clients, mask=255.255.255.0, port=0, dscp=0x0

When I change the ACL of the static to:

access-list Swisscom-VPN extended permit ip host 10.237.214.151 host 10.25.125.9

it doesn't help either, and the packet-tracer stops here:

Phase: 8
Type: NAT
Subtype:
Result: DROP
Config:
nat (Swisscom) 0 0.0.0.0 0.0.0.0
nat-control
  match ip Swisscom any outside any
    no translation group, implicit deny
    policy_hits = 1
Additional Information:
Forward Flow based lookup yields rule:
in  id=0xd7c6b2e0, priority=0, domain=nat, deny=false
        hits=2, user_data=0xd7c6b220, cs_id=0x0, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

As I don't want to bore you guys any further: Do you know whether this scenario is supported by an ASA at all? For me, there's only two possibilities: Either I'm running into a bug, or the ASA won't allow you to source NAT a VPN pool to a different address, or, expressed differently: there's no possibility to do it bidirectionally.

What do you guys think? Am I going to be successful if I open a TAC case? I'm out of ideas now.

Thank you so far, anyway.

Toni

Hey,

I am not sure why you are getting the NAT drop in nat (Swisscom) 0 0.0.0.0  0.0.0.0.

Do you have such a command entered in the first place? Have you tried disabling nat-control to see if that helps?

But yeah go ahead and open up a TAC case. I am sure you will get it resolved much faster that way. I am sure this requirement is still supported. We are just not able to get hold of the problem with the information we have currently.

Regards,

Prapanch

Hi again

I haven't used a NAT exemption on the Swisscom interface, that's why I'm so confused about it. There's no 'nat (Swisscom) 0 0 0' statement in the config.

No, I haven't removed 'nat-control' as this is a productive customer device and I don't want to risk any troubles without being in a maintenance window.

Thanks for your support so far; in case you came across a solution, please let me know.

Regards

Toni

Hello,

The reason you are getting RPF check on that line is because, even though

you are terminating VPN traffic on the outside interface, VPN clients are

treated as internal hosts (belonging to inside network). Can you remove "nat

(outside) 4 access-list vpn_nat_Swisscom outside" and enter "nat (inside) 4

access-list vpn_nat_Swisscom"?

Hope this helps.

Regards,

NT

Hi Nagaraja

As requested, I've changed the outside NAT to a inside NAT for the VPN pool:

access-list vpn_nat_Swisscom extended permit ip vpn-clients 255.255.255.0 object-group Swisscom_gin

nat (inside) 4 access-list vpn_nat_Swisscom

No remedy so far, see the packet-tracer output:

Phase: 7
Type: NAT
Subtype:
Result: DROP
Config:
nat (Swisscom) 0 0.0.0.0 0.0.0.0
nat-control
  match ip Swisscom any outside any
    no translation group, implicit deny
    policy_hits = 2
Additional Information:
Forward Flow based lookup yields rule:
in  id=0xd7c6b2e0, priority=0, domain=nat, deny=false
        hits=3, user_data=0xd7c6b220, cs_id=0x0, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Result:
input-interface: Swisscom
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

The interesting thing is, there is not 'nat (Swisscom) 0' rule configured!

Hi Nagaraja

Now this is interesting, this has changed now:

1.) Packet-tracer reports that the return traffic is allowed! -> see attached file.

2.) There's no xlate entry while trying to send packets to the destination server 10.237.214.151. (Compared to when I source NAT the VPN pool from the outside interface instead of the inside.)

3.) Still, I can't get any traffic through, capture reports zero bytes back and forth:

iconfw(config)# sh capture
capture test type raw-data access-list test interface Swisscom [Capturing - 0 bytes]

4.) ASDM reports that the VPN client has issued a Ping - from outside! This is the only log message appearing:

"IDS:2004 ICMP echo request from 192.168.44.2 to 10.237.214.151 on interface outside"

Please see the current config excerpt attached.

Hello,

Can you run the following packet tracer:

packet-tracer input outside tcp 192.168.44.2 3321 10.237.214.151 21 det

Regards,

NT

Hey Toni,

Hmmm. Could you just paste  the configuration you have currently along with the output of "show crypto ipsec sa" and

"show xlate det | in " when trying to pass traffic from the VPN client to the DMZ server alone? I ll look through it again and see if i can find something from it or try few things out on my side if possible.

Regards,

Prapanch