TCP not working. ICMP and DNS working.

[Spaceman73]

Hi,

I'm hoping someone can help me out a little here.

This started out as a little bit of a lockdown project that I didn't have time to do until now.

First the setup:

Standard home broadband router with wifi (Netgear) (has the network 192.168.0.0/24) Really want to leave this alone as the family connect to it for entertainment etc.
--------------------------------------------------
The broadband router connects to a Cisco 1941 router. Cisco Router has IP NAT configured to get traffic through the broadband router.

interface GigabitEthernet0/0
ip address 192.168.0.2 255.255.255.0
ip nat outside
ip virtual-reassembly in
no ip route-cache
duplex auto
speed auto
end

interface GigabitEthernet0/1
ip address 192.168.10.1 255.255.255.128
ip nat inside
ip virtual-reassembly in
no ip route-cache
duplex auto
speed auto

access-list 7 permit 192.168.0.0 0.0.255.255

ip nat pool no-overload 192.168.0.101 192.168.0.150 prefix-length 24
ip nat inside source list 7 pool no-overload

------------------------------------------------
Cisco router connects to vlan 5 on a cisco 2960
interface GigabitEthernet1/0/1
description LINKTORTR0/0/0
switchport access vlan 5
switchport mode access
spanning-tree portfast

interface Vlan5
description **192.168.10.0/25**
ip address 192.168.10.2 255.255.255.128
ip helper-address 192.168.10.2
no ip route-cache cef
no ip route-cache

Any device connected to the switch on vlan 5 can access the Internet (Currently connected and writing this)

----------------------------------------------
An ASA 5525x is connected to vlan 20 (the outside interface is connected to vlan 5)

Switch configuration to the firewall OUTSIDE interface is configured as:

interface GigabitEthernet1/0/2
description EXT-ASA5516x
switchport access vlan 5
switchport mode access
spanning-tree portfast

Firewall outside interface is:
interface GigabitEthernet0/0
nameif Internet
security-level 0
ip address 192.168.10.10 255.255.255.128

The inside interface is connected to vlan 20 with an IP of 192.168.20.66

Switch configuration to the firewall inside interface is configured as:

interface GigabitEthernet1/0/24
description INT-ASA5516x
switchport access vlan 20
switchport mode access
spanning-tree portfast

The firewall Inside interface is

interface GigabitEthernet0/7
nameif inside
security-level 100
ip address 192.168.20.66 255.255.255.240

The switch VLAN20 is:
interface Vlan20
ip address 192.168.20.65 255.255.255.240
ip helper-address 192.168.20.66
ip directed-broadcast
no ip route-cache cef
no ip route-cache

Completely wide open acl's applies at this point and the inspect allows icmp and dns
-------------------------------------------------

So, A client connected to the switch on vlan 20 gets it's DHCP from the ASA.
IP:192.168.20.67
SM: 255.255.255.240
DG: 192.168.20.66

DNS lookup works a treat:

Default Server: resolver1.opendns.com
Address: 208.67.222.222

> www.bbc.co.uk
Server: resolver1.opendns.com
Address: 208.67.222.222

Non-authoritative answer:
Name: www.bbc.net.uk
Addresses: 212.58.233.251
212.58.237.251
Aliases: www.bbc.co.uk

ICMP also works fine all the way to Google.

However (!) TCP in general doesn't seem to be working. No HTTP, SSL etc.

What I'm seeing in the logs doesn't make a lot of sense to me:

I'm seeing this on occasion:
Apr 24 2020 15:09:12: %ASA-6-106015: Deny TCP (no connection) from 192.168.20.67/63650 to 40.122.160.14/443 flags RST on interface inside

and I'm seeing these:
Apr 24 2020 15:09:11: %ASA-6-106100: access-list inside-in permitted tcp inside/192.168.20.67(62609) -> Internet/40.122.160.14(443) hit-cnt 8 300-second interval [0x503914ad, 0x00000000]
Apr 24 2020 15:09:11: %ASA-6-106100: access-list internet-out permitted tcp inside/192.168.20.67(62609) -> Internet/40.122.160.14(443) hit-cnt 4 300-second interval [0x79a467e6, 0x00000000]

--------------------------------------------------------------

So now the question: What have I done wrong? or what have I missed?
I've spend a couple of days on this now and am now probably too close to the trees to see the woods.

Could someone point my way out of the woods please?

Thanks in advance

[Richard Burts]

The original poster suggests "To be honest this really feels like a routing loop / assymetric routing". It is a tempting theory. But I do not think it is the case. If it were a routing loop or asymmetric routing then I would expect that dns and icmp would be affected.

I believe that the fact that dns and icmp work demonstrates that basic IP connectivity is in place. The fact that (at least some) tcp protocols do not work suggests that something is going on that is sensitive to protocols. I have a couple of suggestions for further testing. In looking at the logs I see tcp attempts using ports 80 and 443. I would like to see testing (and the logs generated during the test) using other tcp protocols (perhaps attempt telnet or ftp or something like that). Also testing so far is to the Internet. I wonder what the result would be if the test attempted to access the switch or the router with a tcp protocol.

[roncro]

hello,

looks like you and I are trying to do the same thing. (I am by no means a Cisco enterprise stuff expert, still struggling to even get to rookie level, but I can get my 2900 router connected to the cable modem/ISP).

Anyway,  putting a switch between your "old netgear" router and you new Cisco router probably won't work. I have been messing with that for days.  Once the modem hands out an address, you won't get another one anymore.

So this is what I did with my Cisco 2900 router,  oh and I have a Cisco DPC3008 cable modem, just a modem, no switch ports.

on the router I connected gi0/0 to he modem and gi0/1 to a switch, and did this:

The gi0/0 needs to be configured with dhcp,  I tried static, never worked.

#conf t
(config)#int gi0/0
(config-if)#ip address dhcp

(config-if)exit
(config)#int gi0/1
(config-if)#ip address 192.168.1.4 255.255.255.0
(config-if)#no shut
(config-if)#exit

(config)#int gi0/0
(config-if)#ip nat out
(config-if)#ip nat outside
(config-if)#int gi0/1
(config-if)#ip nat inside
(config)#ip route 0.0.0.0 0.0.0.0 gi0/0

then it starts whining like: %Default route without gateway, if not a point-to-point interface, may impact performance

(but I think it is ok, since you're not connected to a switch or anything like that)

check what happened with:

#show ip int brief
Interface IP-Address OK? Method Status Protocol
Embedded-Service-Engine0/0 unassigned YES NVRAM administratively down down
GigabitEthernet0/0 a.b.c.d YES DHCP up up     (a.b.c.d is the ip you get from the modem)
GigabitEthernet0/1 192.168.1.1 YES NVRAM up up

then on the router try to ping www.google.com or so.

(you should have gotten your ISP's name-srvers with the dhcp settings too)

again,  I might be way off, but this works for me.

Ron

[Richard Burts]

Ron

Thanks for sharing your experience. I would like to comment about the issue of using a static default route that specifies the outbound interface but does not specify a next hop. It works for you (probably a good thing) but it does have issues (and the issues do not have anything to do with whether it is connected to a switch or not).

- when a static route specifies an outbound interface but not specify a next hop on multi access interfaces like Ethernet the router assumes that every remote destination is locally connected and must arp for EVERY destination as it forwards the traffic. 

- for this to work the next hop router (the ISP in your case) must support proxy arp. Apparently your ISP does support proxy arp but increasingly many organizations are concerned with the security implications of proxy arp and are choosing to not support proxy arp. 

- if proxy arp is not supported then the static default route is just broken and does not work at all. If proxy arp is enabled then the static route does work but it makes the router work much harder.

- if proxy arp is enabled then the arp table is much larger (requires more router memory). And the router has a larger table to search to find the mac of the destination (more cpu cycles). And the router works harder when it must refresh the arp table every 4 hours (more bandwidth to send all the requests, and more cpu cycles to maintain the entries). 

In your situation the impact may not be significant. But for many organizations it could become quite significant. The simple solution would be to configure the static route with both an outbound interface and next hop. Or in cases like yours where the address of the outbound interface is dynamic to use a route like this ip route 0.0.0.0 0.0.0.0 dhcp

[roncro]

Hello Richard,

Thank you for putting me in my place, I just saw you are a "Hall of Fame Master" on this forum, which is very impressive, I, myself, feel I am just struggling to become rookie when it comes to this 'Cisco stuff', or even in computing in general.

However, I am not totally unfamiliar with serious computing, I have been working in large/extreme scale HPC for a good long while.

I definitely respect your point of doing things the correct way the first time, and that it is not a good idea taking any short cuts etc. Which is admirable and also would be my first choice. I noticed your impact here on this forum with this, however, with my experience in extreme scale computing, I learned there might be approaches that are valid because of a different perspective.

In my experience, and also many of my colleagues in the same field, it might just be more beneficial to get "things" going first, even if not ideal, even if really not a good idea, or even if it is a really bad idea, BUT it is still better than being dead in the water. But that is just my world.

I definitively respect your expertise in "arp stuff" etc, and wouldn't even think of questioning you on that topic, or even anything "cisco stuff", but even though I am only a "Cisco rookie", if you ever have a question about anything serious in computing, especially extreme scale computing, including routing and switching in that field, don't hesitate to ask.

respectfully,

Ron

[Richard Burts]

Hello Ron

It was not my intention to put you in your place. I respect your background in large scale computing. In the beginning of my career I was an IBM main frame programmer. So I have some background in large scale computing. Then I got more interested in the networking side of computing and have been working with Cisco gear for 25 years. I remember when I was a beginner with IP networking and am grateful to the people in a community similar to this one who shared what they knew with me. And I try to help rookies as often as I can. 

I offer my perspective and suggest an approach to investigate this issue. I understand that there can be other perspectives and other approaches. If you prefer to take a different approach that is certainly fine. 

[roncro]

no harm done, your post just rubbed me the wrong way.  I can tell from posts here you bring a lot of knowledge and experience to the table, however, not every "newcomer" or "beginner" (as this site calls it) comes in with a completely blank slate.

Interesting you worked with IBM mainframes,  I did too,  I miss that 360/370 era, my first real "IP introduction" was actually on a 390.

I am not completely new to IP networking, I just don't know the first thing about Cisco stuff, IOS, or Cisco's way of doing things and that's why I am here. I am not a stranger to IP networking though, I used to design TCP/IP networks sometimes based on regular network hardware, often based on Infiniband (IB) technology. In my world machines with interconnect speeds of 512Gb between thousands of nodes is the base architecture. So I might know a thing or two about tcp/ip, but wouldn't dare to call myself an expert.

Again, I am here to learn a lot from people that are very experienced using Cisco equipment, I know I am a rookie when it comes to "Cisco stuff", but I am also not the HS kid that knows how to fix grandma's ipad.

My suggestion was, make it work first, then later fix what you don't like, that's why I threw in my 2 cents.

Don't get me wrong though, I do like reading your posts, it is obvious you know what you're talking about.

Ron

[Richard Burts]

Ron

I am sorry that my post rubbed you the wrong way. I have been active in communities like this for a long time and really do try to point out things without being offensive. Sorry that I missed the mark with you. In looking back at the discussion there are 2 things that were in my mind as I wrote my response:

1) questions about static routes that specify an outbound interface without specifying a next hop come up pretty frequently. While sometimes it does work there are also times when it does not work. And when it does work it is a sub optimal solution. I have written about this many times in this community and took this as another opportunity to point out the challenges associated with this.

2) your comment was "(but I think it is ok, since you're not connected to a switch or anything like that)". I acknowledged that this worked for you (and was probably a good thing). What I thought I was doing was to suggest that as you refine your configuration that this was something to address. Sorry that you did not take it that way.

[roncro]

Hi Richard,

Oh I definitely want to refine the setup here, but first want everything going again, before I do that.  I just replaced a bunch of stuff. Of course I have the luxury that when I mess up, since it is a home situation that I use Cisco stuff for, it would only affect me.

Don't get me wrong, I definitely get your point.

thanks,

Ron