cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
522
Views
0
Helpful
1
Replies

ASA holding on to IP

tommygunnah
Level 1
Level 1

After attempting this multiple times I'm unable to properly route traffic to our sonicwall. I know this is a cisco forum but I think the ASA has a setting or something that is keeping the sonicwall from answering a public static IP address for a server we have.

 

Our current static range: 65.1.1.0/28

.1 is used carrier wan rtr

.2 is used for the connection to our sonicwall from carrier rtr

 

.5 is the outside address that our users will be hitting and then NAT to a 10.18.24.248 address on the inside.

 

Basically once I turn of the ASA... I then try to publish an arp entry on the sonicwall so that it can answer the requests. All NAT statements are good but it still doesnt want to come up. Once I switch back to the ASA it takes 30-2 hours before it starts working again.

 

Current setup

 

[Carrier RTR]--.1--------[HP 1920 SW]-------.2--[Sonicwall]

                                                  |

                                                  |

                                                  |

                                           int vlan 2 .6

                                                  |

                                           [ASA 5505]

 

This is the ASA current configuration

 

ASA Version 8.0(4)3
!
hostname ASA
names
name 10.18.24.248 Inside_Server
name 10.18.24.7 Laptop_Inside
name 65.1.1.8 laptop_outside
name 65.1.1.5 Outside_Server
!
interface Vlan1
nameif inside
security-level 100
ip address 10.18.24.6 255.255.248.0
!
interface Vlan2
nameif outside
security-level 0
ip address 65.1.1.6 255.255.255.240
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!

ftp mode passive
clock timezone MST -7
dns server-group DefaultDNS
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
object-group service DM_INLINE_SERVICE_1
service-object icmp
service-object tcp eq https
object-group network DM_INLINE_NETWORK_1
network-object host laptop_outside
network-object host Outside_Server
access-list outside_access_in extended permit object-group DM_INLINE_SERVICE_1 any object-group DM_INLINE_NETWORK_1
access-list inside_nat0_outbound extended permit ip any 10.10.1.0 255.255.255.0
access-list inside_nat0_outbound extended permit ip 10.18.24.0 255.255.248.0 spetz_vpn 255.255.255.0
access-list inside_nat0_outbound extended permit ip 10.18.24.0 255.255.248.0 10.10.1.0 255.255.255.0
pager lines 24
logging enable
logging asdm informational
mtu inside 1500
mtu outside 1500
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-61551.bin
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 0.0.0.0 0.0.0.0
static (inside,outside) Outside_Server Inside_Server netmask 255.255.255.255
access-group outside_access_in in interface outside
route outside 0.0.0.0 0.0.0.0 65.1.1.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
dynamic-access-policy-record DfltAccessPolicy
aaa authentication ssh console LOCAL
aaa authentication enable console LOCAL
http server enable

1 Reply 1

jumora1
Level 1
Level 1

That seems to be an ARP issue but the problem I believe resides on your ISP.

 

See ARP entry values are cleared every 14400 seconds by default on Cisco devices some ISPs might change these to 2 hours or whatever they want.

 

 

You have two options:

 

1. Clear the ARP table of the ISP router. - You might need to call in if you are not hosting an ISP router on your local network that controls the ARP table. 

 

2. Gratuitous ARP

 

When an interface is assigned an IP it sends a Gratuitous ARP letting others know that it has MAC X associated with IP Y. 

 

To achieve this you can statically add that IP to the interface of the SonicWall as soon as you remove it from the ASA, it will take a second or two for the table to be updated if the ISP permits the change.

 

 

Security Engineer
juanmh8419@gmail.com
Skype: juanmh8419@hotmail.com
Review Cisco Networking for a $25 gift card