3

I'm trying to NAT an external address to an internal address which is not local, but on a remote end of a site-to-site VPN connection. Is this possible? Log says Routing failed to locate next hop for TCP from outside x.x.x.x/xxx to inside:y.y.y.y/yyyy

I can connect to the y.y.y.y address just fine, so VPN is up.

nat (outside,outside) source static any any destination static web-server-outside web-server-inside service http tomcat-http
access-list outside_cryptomap extended permit object-group DM_INLINE_SERVICE_1 any object vpn-network 
access-list outside_access_in extended permit object-group DM_INLINE_SERVICE_2 any object-group DM_INLINE_NETWORK_2

object-group network DM_INLINE_NETWORK_2
 network-object object web-server-inside
 network-object object web-server-outside
object-group service DM_INLINE_SERVICE_2
 service-object tcp destination eq www 
 service-object tcp destination eq https 
 service-object object tomcat-http 

Result of the command: "packet-tracer input outside tcp 8.8.8.8 1234 x.x.x.x 80 detailed"

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (outside,outside) source static any any destination static web-server-outside web-server-inside service http tomcat-http
Additional Information:
NAT divert to egress interface outside
Untranslate x.x.x.x/80 to 10.y.y.y/8080

Phase: 2
Type: ACCESS-LIST
Subtype: 
Result: DROP
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xadc473e8, priority=111, domain=permit, deny=true
    hits=3395573, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0
    dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
    input_ifc=outside, output_ifc=outside

Result:
input-interface: outside
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

Here's trace after allowing intrainterface traffic:

    Result of the command: "packet-tracer input outside tcp 8.8.8.8 1234 x.x.x.x 80 detailed"

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (outside,outside) source static any any destination static web-server-outside web-server-inside service http tomcat-http
Additional Information:
NAT divert to egress interface outside
Untranslate x.x.x.x/80 to y.y.y.y/8080

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit object-group DM_INLINE_SERVICE_2 any object web-server-inside 
object-group service DM_INLINE_SERVICE_2
 service-object object http 
 service-object object http-tomcat 
 service-object object https 
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xae825a98, priority=13, domain=permit, deny=false
    hits=16, user_data=0xaa5f12c0, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0
    dst ip/id=y.y.y.y, mask=255.255.255.255, port=8080, dscp=0x0
    input_ifc=outside, output_ifc=any

Phase: 3
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xadc4acf0, priority=0, domain=inspect-ip-options, deny=true
    hits=22335785, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0
    dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
    input_ifc=outside, output_ifc=any

Phase: 4
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xadc42e48, priority=21, domain=lu, deny=true
    hits=8829, user_data=0x0, cs_id=0x0, flags=0x0, protocol=6
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0
    dst ip/id=0.0.0.0, mask=0.0.0.0, port=80, dscp=0x0
    input_ifc=outside, output_ifc=any

Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xad421098, priority=13, domain=ipsec-tunnel-flow, deny=true
    hits=22393564, user_data=0x0, cs_id=0x0, flags=0x0, protocol=0
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0
    dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
    input_ifc=outside, output_ifc=any

Phase: 6
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (outside,outside) source static any any destination static web-server-outside web-server-inside service http tomcat-http
Additional Information:
Static translate 8.8.8.8/1234 to 8.8.8.8/1234
 Forward Flow based lookup yields rule:
 in  id=0xafd6da48, priority=6, domain=nat, deny=false
    hits=26, user_data=0xae843690, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0
    dst ip/id=y.y.y.y, mask=255.255.255.255, port=8080, dscp=0x0
    input_ifc=outside, output_ifc=outside

Phase: 7
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (outside,outside) source static any any destination static web-server-outside web-server-inside service http tomcat-http
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0xae2c6960, priority=6, domain=nat-reverse, deny=false
    hits=26, user_data=0xae835d18, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0
    dst ip/id=y.y.y.y, mask=255.255.255.255, port=8080, dscp=0x0
    input_ifc=outside, output_ifc=outside

Phase: 8
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 in  id=0xadc4acf0, priority=0, domain=inspect-ip-options, deny=true
    hits=22335787, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0
    dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
    input_ifc=outside, output_ifc=any

Phase: 9
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 23045025, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_translate
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Module information for reverse flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
MK.
  • 292
  • 1
  • 4
  • 13
  • Yeah - it's possible. Can you please edit your question to include the relevant parts of the config (crypto maps and their ACLs, routes, and NAT rules), with private info scrubbed, so that we can assist in figuring out what's not working right? – Shane Madden Aug 25 '11 at 22:30
  • I can't post too much. I don't think NAT is relevant, for example, because I have a bunch of rules that look the same (except address is local, not via vpn) and work.... I was hoping for a hint on direction were to dig -- where is this kind of routing set up? – MK. Aug 26 '11 at 00:36
  • @MK Depends. Does your tunnel terminate on the outside interface? If so, you'll be turning around the addressing with a NAT (`static (outside,outside)`) and sending it right out the tunnel - no routing involved. Another important item, if that's the architecture: `same-security-traffic permit intra-interface`. Very different if it's different interfaces for `x.x.x.x` and the tunnel, though. – Shane Madden Aug 26 '11 at 01:36
  • yes, good point, vpn is on outside, so I changed the nat to be outside,outside and now I'm just getting denied by implicit rule. So somehow it's not hitting my ACL. I'll update the question with some of the rules, please take a look. – MK. Aug 26 '11 at 04:48
  • @MK Might just be an issue with your `outside_access_in` - probably needs to have a more permissive source used instead of the same object for the destination. Beyond that, check `packet-tracer`, see where it's going and if it hits the NAT and the encryption correctly. – Shane Madden Aug 26 '11 at 05:37
  • @Shan NAT rule hits and says untranslate [outside address]/80 [inside address]/8080 which is correct. Then it says ACCESS-LIST - dropped by an implicit rule. So somehow my outside_access_in is not matching, but how? – MK. Aug 26 '11 at 13:39
  • @MK Again, if your `outside_access_in` is what you've posted above, then only the web server will be able to get to the web server. Source address on that rule needs to be the source address of allowed clients. – Shane Madden Aug 26 '11 at 16:46
  • @Shane that rule does have any in it, that's any for the source address. I think you misread it. I tried changing it to allow to any from any for all tcp and it still didn't work. I don't think it realizes that it should route the packet to VPN, but what can I do about it? – MK. Aug 26 '11 at 19:49
  • @MK Yup, sure did. Which implicit rule does it cite when `packet-tracer` says it drops? – Shane Madden Aug 26 '11 at 20:03
  • @Shane updated with packet-tracer output. It's not matching my allow rules and goes to implicit deny all rule. – MK. Aug 26 '11 at 20:17
  • @MK You've got `same-security-traffic permit intra-interface` and `access-group outside_access_in in int outside` configured, right? Maybe put an explicit deny any any at the bottom of `outside_access_in`, and turn up logging on it? – Shane Madden Aug 26 '11 at 20:31
  • same-security-traffic helped somewhat -- the packet-tracer now shows that the packet is allowed. However the connection is not established and tcpdump on the VPN peer doesn't see the packets hitting it... – MK. Aug 26 '11 at 21:12
  • Does the `packet-tracer` show the VPN encrypt step? Any logs of IKE attempts? – Shane Madden Aug 26 '11 at 22:23
  • @Shane I updated with the new packet-trace. I see the VPN step but it says deny=true... but continues. IKE is already established at that point, the VPN link is always up. If I run telnet y.y.y.y 8080 on the system behind this ASA it works. – MK. Aug 27 '11 at 19:23

0 Answers0