Hi, Good day to all!
I'm having issues accessing my device/router as well as discovering from my poller via snmp. We notice that this issue happens on a certain time. Here's sample output of the issue which I can't connect from our remote server.
Note: that I can ping the device without any packet loss, Plus no interruption on its routing protocol.
ssh 172.27.136.222 ssh: connect to host 172.27.136.222 port 22: Connection timed out or sometimes it gets stuck after typing the password Password: <stuck>
After issuing the "show users" I'm able to see my remote server address, means that the server can connect but somehow get's interrupted. (Note: I'm able to access the router thru a backdoor)
During the investigation, I ran a packet capture to verify what is actually happening .
Link(Photo): https://ibb.co/DktB6pK
From the link you will see two set of communication, the one Above photo is the time that device is unable to remote and the Below photo is the time that we can access the device.
a. Above photo (ssh not working):
Notice that 192.168.200.200 (remote server) sent a SYN (random ports-54656 / tcp-22) but I see different address send the reply as opposed to the destination ip which is 172.27.136.22...and after that 192.168.200.200 (remote server) sends a re transmission.
b. Below photo(ssh working):
Notice that 192.168.200.200 (remote server) sent a SYN (random ports-32824 / tcp-22) but here I see that the router mgmt ip sends a reply which is correct.
Forwarding: REMOTE SERVER -----> HUB(Tun100) ------> (Tun100)SPOKE(loopback99-mgmt) 192.168.200.200 172.27.136.222 Response: REMOTE SERVER <----- HUB(Tun100) <------ (Tun100)SPOKE(loopback99-mgmt) 192.168.200.200 172.27.136.222 Configuration: interface Loopback1 ip address 10.118.2.45 255.255.255.255 ! interface Loopback99 description Management ip address 172.27.136.222 255.255.255.255 ! interface Tunnel100 ip address x no ip redirects ip mtu 1400 ip nat outside ip pim nbma-mode ip pim sparse-mode ip nhrp map x ip nhrp map x ip nhrp network-id 23 ip nhrp holdtime 500 ip nhrp nhs x ip nhrp redirect zone-member security IN_ZONE ip tcp adjust-mss 1360 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel vrf ISP tunnel protection ipsec profile SPK_PROF shared ! ip nat translation timeout 14400 ip nat translation tcp-timeout 14400 ip nat inside source route-map NTPOL interface Loopback1 overload ! route-map NTPOL permit 10 match ip address ACL:NTPOL match interface Tunnel100 ! ip access-list extended ACL:NTPOL permit tcp any host 10.125.156.118 eq 8080 permit tcp any host 10.125.156.200 eq 1352 permit tcp any host 10.125.156.201 eq 1352 permit tcp any host 10.125.156.206 eq 1352 permit tcp any 141.251.0.0 0.0.255.255 permit tcp any 134.177.0.0 0.0.255.255 permit tcp any 192.32.0.0 0.0.255.255 permit udp any any range 3478 3481 permit udp any any range 50000 59999 permit tcp any any range 50000 59999 permit tcp any any eq 443 ! adnt-pa0869rz1#sh ip access-lists ACL:NTPOL <-------- NO MATCHES? Extended IP access list ACL:NTPOL 10 permit tcp any host 10.125.156.118 eq 8080 20 permit tcp any host 10.125.156.200 eq 1352 30 permit tcp any host 10.125.156.201 eq 1352 40 permit tcp any host 10.125.156.206 eq 1352 70 permit tcp any 192.32.0.0 0.0.255.255 80 permit udp any any range 3478 3481 90 permit udp any any range 50000 59999 100 permit tcp any any range 50000 59999 <---- seems like due to this? 110 permit tcp any any eq 443 NAT TRANSLATION: Pro Inside global Inside local Outside local Outside global tcp 10.118.2.45:640 172.27.136.2:22 192.168.200.200:58758 192.168.200.200:58758 tcp 10.118.2.45:640 172.27.136.2:22 192.168.200.200:59150 192.168.200.200:59150
Question:
- So we can see that NAT affects the ssh connection but how does the router/remote server selects the source port is this randomly generated?
- This issue normally happens during office hours can we somehow link this to the volume of client(note no congestion)?
- Also why router is translating Loopback99-mgmt ip even if NAT is not enable or loopback doesn't have ip nat inside?
- What possible solution can we use?
Thanks
No comments:
Post a Comment