Martpher7
asked on
Cisco ASA Inside hosts cannot access the internet
Hello team,
I am having an issue where I cannot browse the internet from my inside host 192.168.0.20, I keep getting this " Deny TCP (no connection) from 192.168.0.20/59705 to 192.168.0.10/443 flags FIN ACK on interface INSIDE" .
This is strange because I am able to ping 8.8.8.8 and get a reply but cannot get a reply from my web browser.
I am running version 8.4 on my asa5505, see config below
interface Vlan1
nameif OUTSIDE
security-level 0
ip address dhcp setroute
!
interface Vlan2
nameif INSIDE
security-level 100
ip address 192.168.0.10 255.255.255.0
object network INSIDE_NETWORK
subnet 192.168.0.0 255.255.255.0
nat (INSIDE,OUTSIDE) source dynamic INSIDE_NETWORK interface
route OUTSIDE 0.0.0.0 0.0.0.0 68.195.48.1 1
I have tried many things including,
- creating ACLs for inside_access_out and also Outside_Access_In
I am having an issue where I cannot browse the internet from my inside host 192.168.0.20, I keep getting this " Deny TCP (no connection) from 192.168.0.20/59705 to 192.168.0.10/443 flags FIN ACK on interface INSIDE" .
This is strange because I am able to ping 8.8.8.8 and get a reply but cannot get a reply from my web browser.
I am running version 8.4 on my asa5505, see config below
interface Vlan1
nameif OUTSIDE
security-level 0
ip address dhcp setroute
!
interface Vlan2
nameif INSIDE
security-level 100
ip address 192.168.0.10 255.255.255.0
object network INSIDE_NETWORK
subnet 192.168.0.0 255.255.255.0
nat (INSIDE,OUTSIDE) source dynamic INSIDE_NETWORK interface
route OUTSIDE 0.0.0.0 0.0.0.0 68.195.48.1 1
I have tried many things including,
- creating ACLs for inside_access_out and also Outside_Access_In
Is 0.20 the only address with this issue? Check your access rules and make sure you do not have any deny rules for 0.20. You may have deny rules for 443 "https" and 80 "http" you will still be able to ping 8.8.8.8 because you may have icmp allowed.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi Martpher,
Kindly share the firewall config and ipconfig /all output from your machine.
Try the below:
I)
Nslookup from the workstation for any external ip address
Open the cmd...type nslookup...once u enter this prompt >, type server 8.8.8.8......then it would change the default dns server to 8.8.8.8...
Then type google.com and check if it resolves to an ip address.
II)
Check the telnet to port 80 n 443 to verify if the firewall rules are in place.
III)
Use the packet tracer utility to find the exact point where the traffic gets blocked
Kindly share the firewall config and ipconfig /all output from your machine.
Try the below:
I)
Nslookup from the workstation for any external ip address
Open the cmd...type nslookup...once u enter this prompt >, type server 8.8.8.8......then it would change the default dns server to 8.8.8.8...
Then type google.com and check if it resolves to an ip address.
II)
Check the telnet to port 80 n 443 to verify if the firewall rules are in place.
III)
Use the packet tracer utility to find the exact point where the traffic gets blocked
I think you may have configured a very broad NAT rules which causes the firewall to proxy-ARP traffic destined for the internet, perhaps port specific. Otherwise you shouldn't see the inside interface as the denied destination.
Please post output from "show run nat" if possible.
Please post output from "show run nat" if possible.
what is the default gateway configured on your internal machines?
I would think that ASAVENER is leading you towards the answer. To me, that message means that the ASA is seeing a packet for which it does not believe there is an open session/connection. The ASA needs to see all the necessary packets to make sure that the session is alive. I'll explain.
So when you send a ping, it is udp/ICMP, and it has no session. Just a source and destination, and a couple other flags to indicate whether it is an echo, echo reply, unreachable, etc. From the ASA's standpoint, each packet is inspected individually without any correlation to a previous ICMP packet. So let's say you send the echo to destination X. The reply to that echo can potentially get back to the originating device using any path - regardless of the path going back through the ASA. As long as your machine gets the reply, it appears to you that things are working correctly.
Now, let's consider TCP sessions such as HTTP. To get a session going, you must follow some steps - Originator sends a SYN, receiver replies with SYN ACK, and session setup information continues to go back and forth. When the ASA sees a SYN packet, it starts paying attention to the session. The ASA knows that it must see both sides of the conversation to verify that the session is valid. If the ASA can only see one side, it will block the connection.
Checking the default gateway on devices and verifying the data path both directions will be helpful.
So when you send a ping, it is udp/ICMP, and it has no session. Just a source and destination, and a couple other flags to indicate whether it is an echo, echo reply, unreachable, etc. From the ASA's standpoint, each packet is inspected individually without any correlation to a previous ICMP packet. So let's say you send the echo to destination X. The reply to that echo can potentially get back to the originating device using any path - regardless of the path going back through the ASA. As long as your machine gets the reply, it appears to you that things are working correctly.
Now, let's consider TCP sessions such as HTTP. To get a session going, you must follow some steps - Originator sends a SYN, receiver replies with SYN ACK, and session setup information continues to go back and forth. When the ASA sees a SYN packet, it starts paying attention to the session. The ASA knows that it must see both sides of the conversation to verify that the session is valid. If the ASA can only see one side, it will block the connection.
Checking the default gateway on devices and verifying the data path both directions will be helpful.
Is .20 trying to use .10 as a proxy server?
ASKER
Thanks much guys, its working now.
So, the problem was that I needed to add a Primary DNS on my inside hosts to one listed from my Optimum router, soon as I added the DNS i was able to browse the internet.
I did try using 8.8.8.8 as Primary DNS but it didn't work, only when I used one from the router.
So its all good now.
Thanks again
So, the problem was that I needed to add a Primary DNS on my inside hosts to one listed from my Optimum router, soon as I added the DNS i was able to browse the internet.
I did try using 8.8.8.8 as Primary DNS but it didn't work, only when I used one from the router.
So its all good now.
Thanks again