Cisco 5505 Site-to-Site

On the ISA I put the logging on to log anything coming from the ASA LAN. It logged everything that was destined to my 10.0.0.0 LAN (Domain Controllers, Fileservers, etc), but when I left the logging running on the ISA and tried a ping from the ASA network, nothing came through on the ISA (no logs).

Interestingly enough, if I did "telnet www.google.co.uk 80" from the ASA network the screen cleared like it connected, but again, nothing came through on ISA (no logs).
 
oldbag said:
On the ISA I put the logging on to log anything coming from the ASA LAN. It logged everything that was destined to my 10.0.0.0 LAN (Domain Controllers, Fileservers, etc), but when I left the logging running on the ISA and tried a ping from the ASA network, nothing came through on the ISA (no logs).

Interestingly enough, if I did "telnet www.google.co.uk 80" from the ASA network the screen cleared like it connected, but again, nothing came through on ISA (no logs).
Click to expand...

That suggests you only have SA's for the local and remote lans's on both the asa and the ISA server. Run the packet tracer command a couple of times on the ASA then check the SA's to see if it will establish SA's for anything else but the HQ lan.

packet-tracer input inside udp 10.0.0.10 12345 8.8.8.8 53 detailed

sh crypto ipsec sa
 
My only thought was that because I have a

route outside 0.0.0.0 0.0.0.0 <public ip of ISP next Hop> 1 (which is the ASA syntax)

That when you try and access something that isn't 10.0.0.0 it thinks it should be sent out the outside interface directly to the Internet (even though my crypto rule is any).

I cant remove the route outside 0.0.0.0 0.0.0.0 <public ip of ISP next Hop> 1 as the ASA needs it to get onto the Internet to establish the tunnel.
 
So, how would this work - ip route 1.2.3.4 255.255.255.255 5.6.7.8 if the syntax on the ASA is: Route if_name ip_address netmask gateway_ip [metric] ? Multiple route outside statements?
 
I'm guessing 'route outside 1.2.3.4 255.255.255.255 5.6.7.8 10' would be about right (including metrics is good practice really, though the actual metric is irrelevant here using something other than 1 allows you to add a preferential route in later without removing the existing one).
 
Hrm, well a packet trace does this:

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group acl_in in interface inside
access-list acl_in extended permit ip 10.0.x.x 255.x.x.x any log
Additional Information:

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

Phase: 5
Type: NAT-EXEMPT
Subtype:
Result: ALLOW
Config:
match ip inside 10.0.X.X 255.X.X.X outside any
NAT exempt
translate_hits = 296, untranslate_hits = 3
Additional Information:

Phase: 6
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

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

So by my guessing it's not encrypting the packets, any idea why?
 
You must log in or register to reply here.
Back
Top Bottom