cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6150
Views
0
Helpful
4
Replies

Asa is using wrong egress interface after VPN - NAT

Uhlig.Tim
Level 1
Level 1

Hey together,

 

Situation:

Site-to-Site VPN with NAT between two ASAs

My SAP colleagues asked me to build a vpn to a partner of them.

Private ip (server sap) - NAT (our public space) - VPN - Partner (their public range) - NAT to their local private ip (server sap).

 

What I've done:

I built a IPSec ikev1 vpn, which is working, as I can see on the ASA (counters are increasing)

 

What's the problem:

If the partner is sending packets to the given public ip of us, no packet is arriving on our internal server. 

Our ASA is using the wrong egress Interface.

 

Nat-Rule:

webaccess01# sho run nat
nat (inside,outside) source static schde-sa-cab0.ag.schoeck.com external_schde-sa-cab0.schoeck.com destination static SeebergerRemote SeebergerRemote

 

schade-sa-cab0... is our internal server with a private ip (10.51.10.1)

externel_schde-sa-cab0.. is the server translated into the public ip (194.59.23.33)

SeebergerRemote... is the public ip subnet of our partner (217.7.130.224/27)

 

From us to partner

If I use packet-tracer the packets is handled correctly and using the vpn as expected.

 

Packet-tracer results:

webaccess01# packet-tracer input inside tcp 10.51.10.1 80 217.7.130.226 80

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static schde-sa-cab0.ag.schoeck.com external_schde-sa-cab0.schoeck.com destination static SeebergerRemote SeebergerRemote description Steuerfinanzen Ungarn - SAP zu Seeberger - NAT intern zu DMZ
Additional Information:
NAT divert to egress interface outside
Untranslate 217.7.130.226/80 to 217.7.130.226/80

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.123.1.42 using egress ifc inside

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_access_in in interface inside
access-list inside_access_in remark Steuerfinanzen fr Ungarn - SAP zu Seeberger
access-list inside_access_in extended permit ip object-group DM_INLINE_NETWORK_98 object-group SeebergerRemote
object-group network DM_INLINE_NETWORK_98
network-object object schde-sa-cab0.ag.schoeck.com
network-object object schde-sa-qas0.ag.schoeck.com
object-group network SeebergerRemote
network-object object Seeberger-DMZ
Additional Information:

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static schde-sa-cab0.ag.schoeck.com external_schde-sa-cab0.schoeck.com destination static SeebergerRemote SeebergerRemote description Steuerfinanzen Ungarn - SAP zu Seeberger - NAT intern zu DMZ
Additional Information:
Static translate 10.51.10.1/123 to 194.59.23.33/123

Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: SFR
Subtype:
Result: ALLOW
Config:
class-map sfr
match access-list sfr_redirect
policy-map global_policy
class sfr
sfr fail-open monitor-only
service-policy global_policy global
Additional Information:

Phase: 8
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: FLOW-EXPORT
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static schde-sa-cab0.ag.schoeck.com external_schde-sa-cab0.schoeck.com destination static SeebergerRemote SeebergerRemote description Steuerfinanzen Ungarn - SAP zu Seeberger - NAT intern zu DMZ
Additional Information:

Phase: 12
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 13
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 14
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 15
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 1321179, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

 

 

 

From partner to us

The packet is being translated correctly, but ASA is using the wrong egress interface (outside instead of inside)

 

Packet-tracer results (from partner to us):

webaccess01# packet-tracer input outside tcp 217.7.130.226 80 194.59.23.33 80

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static schde-sa-cab0.ag.schoeck.com external_schde-sa-cab0.schoeck.com destination static SeebergerRemote SeebergerRemote description Steuerfinanzen Ungarn - SAP zu Seeberger - NAT intern zu DMZ
Additional Information:
NAT divert to egress interface inside
Untranslate 194.59.23.33/80 to 10.51.10.1/80

 

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 217.7.130.226 using egress ifc outside

Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

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

 

 

 

End

Do you have any idea what could be wrong?

If you need complete asa config - let me know, but its messed up by ASDM, as the company was just using ASDM to configure the firewall before I started working there.

To show you the remote ASA config is impossible, but its not necessary, as the issue is caused by our ASA.

To exclude an "old" bug, I've upgraded our ASA to 9.8.2.38.

 

Thanks in advance! I would appreciate some helping answers

 

 

cheers Tim 

2 Accepted Solutions

Accepted Solutions

Uhlig.Tim
Level 1
Level 1

I figured out the issue.

 

Depending on the firmware version of the ASA the configuration is different.

 

On older versions you needed to configure a rule which allows traffic from your public IP to your internal private ip.

 

In newer versions you need to configure a rule which allows traffic from the remote public ip your internal private ip.

View solution in original post

Uhlig.Tim
Level 1
Level 1

I figured out the issue.

 

Depending on the firmware version of the ASA the configuration is different.

 

On older versions you needed to configure a rule which allows traffic from your public IP to your internal private ip.

 

In newer versions you need to configure a rule which allows traffic from the remote public ip to your internal private ip.

 

In my case, we need the remote public ip.

View solution in original post

4 Replies 4

Bogdan Nita
VIP Alumni
VIP Alumni

I do not think the second packet-tracer is falling because of the wrong egress interface.

It fails because of the access-list on the outside interface.
If the ASA were running 9.9 you could use decrypted keyword at the end of the packet-tracer, to simulate a decrypted packet.

If you have a look at the first packet-tracer, route-lookup is saying "found next-hop 10.123.1.42 using egress ifc inside", but the packet is sent out the outside interface, according to the result.

 

HTH

Bogdan

Thanks for your answer.

 

There is a rule on the outside interface, allowing remote Public subnet to our public subnet (permit ip from 217.7.130.224/27 to 194.59.23.32/27)

Is that what you mean?

Uhlig.Tim
Level 1
Level 1

I figured out the issue.

 

Depending on the firmware version of the ASA the configuration is different.

 

On older versions you needed to configure a rule which allows traffic from your public IP to your internal private ip.

 

In newer versions you need to configure a rule which allows traffic from the remote public ip your internal private ip.

Uhlig.Tim
Level 1
Level 1

I figured out the issue.

 

Depending on the firmware version of the ASA the configuration is different.

 

On older versions you needed to configure a rule which allows traffic from your public IP to your internal private ip.

 

In newer versions you need to configure a rule which allows traffic from the remote public ip to your internal private ip.

 

In my case, we need the remote public ip.