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

Weird NAT behaviour

Dan Jay
Level 1
Level 1

Folks,

I'm on a 886VAW ( 15.1(4r)M ). I have a setup  as follows:

One internal host is portforwarded via static NAT ( NAS with an app on it which I want to publish ).

Other hosts are dynamically NATed.

All internal hosts to be excluded from NAT for certain VPN destinations ( RFC 1918 <-> RFC1918 ).

The WAN link is a 6 MBit ADSL line nailed down via ATM.

I have only one dynamic 24h - WAN IP and, in this sceanrio, I need to use static and dynamic NAT together.

The DDNS is performed via NO-IP.

There is no packet filter anywhere ( yet ).

All engines running nicely, but I cannot reach the forwarded host under certain conditions from the outside.

The behavior is this:

iPhone app connecting via 3G to the host app --> OK, everything runs.

iPhone tethered to a Laptop, Laptop connects to the host app via the iPhone 3G --> OK everything running.

Office machine running off a SDSL link behind a ASA5510 -> OK, everything running.

BUT:

Normal Standalone PCs ( independent of OS, location / machine type etc ) and non-Iphones ( meaning samsung and the like ):

The application loads partly; I can see the title of the program in the Firefox tab. AGES later the splash screen comes alive.

Then the browser freezes.

These machines run off normal consumer DSL lines or 3G cellular service.

Bandwidth is NOT an issue.

Again, BUT:

A standalone PC as mentioned above, tethered via personal hotspot to the iPhone, CONNECTS !!!

So much for confusion.

According to the NAT table, the connection IS established:

#sho ip nat trans

Pro Inside global         Inside local          Outside local         Outside global

tcp 91.2.80.88:80         192.168.2.100:80      89.13.161.161:49274   89.13.161.161:49274

tcp 91.2.80.88:80         192.168.2.100:80      ---                   ---

Here's my setup. I can not figure what is causing this behavior....The ACLs in square brackets are for VPN control ( remaining VPN setup not posted here ). There is only 1 Dialer ( even if the one below has the index #2 ).

interface Dialer2

ip ddns update ***

ip ddns update *****

ip address negotiated

ip mtu 1492

ip nat outside

ip virtual-reassembly in

encapsulation ppp

ip tcp adjust-mss 1452

dialer pool 2

dialer idle-timeout 90

dialer string "*99#"

dialer-group 1

ppp authentication pap callin

ppp pap sent-username ****

ppp ipcp dns accept

ppp ipcp mask request

ppp ipcp route default

ppp ipcp address accept

no cdp enable

crypto map ****

ip nat inside source static tcp 192.168.2.100 80 interface Dialer2 80

ip nat inside source route-map natexclude interface Dialer2 overload

ip route 0.0.0.0 0.0.0.0 Dialer2

access-list 90 permit 192.168.0.0 0.0.255.255

access-list 120 permit ip 192.168.2.0 0.0.0.255 any

[access-list 198 deny   ip 192.168.2.0 0.0.0.255 172.16.0.0 0.0.255.255]

[access-list 198 deny   ip 192.168.2.0 0.0.0.255 192.168.20.0 0.0.0.255]

access-list 198 permit ip 192.168.2.0 0.0.0.255 any

[access-list 199 permit ip 192.168.2.0 0.0.0.255 192.168.0.0 0.0.255.255]

[access-list 199 permit ip 192.168.2.0 0.0.0.255 172.16.0.0 0.0.255.255]

dialer-list 1 protocol ip list 120

no cdp run

!

!

route-map natexclude permit 10

match ip address 198

1 Reply 1

barnesp
Level 1
Level 1

In you failed scenario have thought of running a packet capture on the PC it may give some hints. Use Wireshark which free. One possible cause could be an MTU issue.

You could reduce ip tcp adjust-mss to a lower value.

Sent from Cisco Technical Support iPad App

Review Cisco Networking for a $25 gift card