10-23-2014 12:50 PM - edited 03-05-2019 12:01 AM
Guys,
I'm facing an issue in a customer whenever a linux workstation (ubuntu) is trying to reach the customer's webmail. The interesting is the windows desktops, connected within the same VLAN doesn't show the same issue. It is happening in fact only for the linux desktops.
The inter-vlan routing is done by a 2851 router, with IOS 12.4. It is also a Call Manager Express.
One interesting thing: when I try to telnet the website's ip address, from the linux, at the tcp port 80, I just can't (no answer). But, when I telnet from the router, to the same ip address, sourced by interface vlan ip address, I can. I attached a file with a couple of print screens.
Does anyone have an idea?
Thanks!
Karl
Solved! Go to Solution.
10-28-2014 01:51 PM
Karl,
I can't see this being a Cisco issue. This sounds like to me you have an issue with the server. You can get to other websites okay, and you can ping the webmail server, but you can't get to it. I'm assuming that you can't get to it by name on 80 or by ip address on 80. Is there something that your host could be doing that could be causing a tcp reset? Have you tried to run tcpdump on the server while you do a telnet? I'm not sure where your problem is exactly... Have you tried removing your inspects to see if that could be causing your issue?
John
10-23-2014 04:49 PM
We may need to see your nat config. The issue itself doesn't make any sense. Can you ping 8.8.8.8 from this host by chance?
HTH,
John
10-24-2014 04:12 AM
John,
I can ping the webmail address from the linux and I can telnet a couple more websites at the tcp/80 port, except by the company's webmail itself.
I'm sorry to not have attached the config before - sure it was a lack of attention from myself. I attached the running-config. I just removed the Call Manager configuration, as it is a long list of IP phones and dial-peer rules.
With wireshark I can see only the TCP SYN packets and no answer coming from the webmail. Besides, checking the nat translation table I can see the linux IP address there, therefore, it was successfully translated.
Using the "show ip inspect session" command and I can also see the session stuck at the OPENING state, neither opened nor closing.
More information:
- The ip address 172.20.1.1 is the local internet provider IP and it matches the Gigabit0/1.1001 IP address;
- There is only a single layer 2 switch between the linux desktop and the router, which is the default gateway and also plays the role of a single local firewall.
Thanks for your attention!
Karl
10-24-2014 04:49 AM
I don't see anything that jumps out as incorrect in the config. You said that Windows workstations work? Can you create an acl that matches on this one host going to anything and anything coming to this one host, and then create a debug that matches on that host to see what it's doing in the router?
access-list 101 permit ip host 172.16.64.188 any
access-list 101 permit ip any host 172.16.64.188
debug ip packet 101 deta
Try to get to the host and then post the results of the debug. Also, is this the only destination address that doesn't work on 80 or can this host not get to any websites at all?
HTH,
John
10-28-2014 06:25 AM
John,
Windows worstations are working fine. The interesting is from the Linux is possible to access any other website and the issue is only for one website - coincidence or not, it's the webmail of this company. From the Linux I can ping the website, but I can't telnet it at tcp port 80. From the router I can ping as well as telnet it at tcp port 80.
Where do you want me to apply this ACL? There is already one ACL applied at the exit interface GigabitEthernet0/1.1001. Besides, don't you think a debug like that at the production router would crash it?
Thanks for your support!
Regards,
Karl
10-28-2014 06:44 AM
This acl ties the particular host to the debug, so you'll only get traffic from the one host and shouldn't crash the router.
I'm not understanding what your issue is now though. Let me try to recap:
You can get to the internet from the Linux host?
You cannot get to the webmail interface from the Linux host which is internal?
If the above is correct, are you trying to telnet to the public address from inside on 80, or are you trying to connect to 80 on the internal address?
10-28-2014 09:33 AM
John,
I drew a simple topology in order to help a little bit.
Recap:
a) Windows workstations can access everything inside Internet;
b) Linux workstations can acess everything inside Internet except by the webmail address. Whenever you open a browser, after typing the URL you the browser got stuck until time-out. Then, when I started troubleshooting, I realized that Linux worstations can ping the server (ICMP is fine) but I can't telnet it at tcp port 80 (simulating a browser requisition).
Doing the same telnet (tcp/80) from the router, I receive a response from the webmail server. Ping is also fine from the router.
Linux and Windows are within the same VLAN.
Can I make myself clear? Sometimes typing is a bit complicated! =)
Regards,
Karl
10-28-2014 01:51 PM
Karl,
I can't see this being a Cisco issue. This sounds like to me you have an issue with the server. You can get to other websites okay, and you can ping the webmail server, but you can't get to it. I'm assuming that you can't get to it by name on 80 or by ip address on 80. Is there something that your host could be doing that could be causing a tcp reset? Have you tried to run tcpdump on the server while you do a telnet? I'm not sure where your problem is exactly... Have you tried removing your inspects to see if that could be causing your issue?
John
10-29-2014 02:56 AM
John,
I'm not sure about as this being an issue at the router either. The point is until now I don't know how I could check whether the traffic from the Linux workstations is passing through the router or not. Do you have any idea?
The webmail server is hosted somewhere in the internet and I don't have access to it. I started the wireshark in a Linux workstation and I can see only the TCP SYN. Really it seems to be something related to the webmail server.
Besides, I checked the ip inspection and I can see the "OPENING" sessions, but neither OPENED nor CLOSING can be seen. I removed the ip inspection to make a test, but it doesn't do any difference. Do you think the output from "show ip inspection session" can give me a guarantee that at least the packets are going out the router?
Thanks once more!
Karl
10-29-2014 03:55 AM
"The point is until now I don't know how I could check whether the traffic from the Linux workstations is passing through the router or not. Do you have any idea?"
That's what the debug above would do....you could tie the acl down to being only port 80 from that server if you wanted. I don't believe ip inspects will show until a session is created. If you're only seeing syn packets on the server and not the rest of the handshake, it doesn't sound like it's being created for some reason...
11-14-2014 04:00 AM
John,
After a "looooong winter" (lol) I'm concluding that there is some equipment in between doing the blocking.
THe output from "show ip inspect session" shows me the connections are trying to be opened, but no answer is received. I also checked the NAT translation table, and the translation in being done finely.
The customer has another internet connection and even so the problem is kept.
Interestingly, the linux can't access only the customer's webmail. I tried some other webmails and all of them were fine.
I told him to talk to his internet provider in order to check anything else could be blocking only the linux access. There is a chance his webmail hosting provider could also be blocking somehow.
Anyway, I'm finishing this case with the customer.
I appreciate your time and patience!
Cheer,
Karl
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide