How to get access to port 8000?

[eferland]

I had a issue getting to my VPN device from outside my network on port 444. A Cisco tech helped me fix it last night but now I can't get to the device via the internal IP and using port 8000? It worked fine before the tech helped me get access which I'm grateful for but how do I get access back?

I'm using a ASA 5510

Result of the command: "show run nat"

nat (inside,outside) source static 10.0.0.0 10.0.0.0 destination static 10.0.1.0 10.0.1.0 no-proxy-arp route-lookup

!

object network obj-10.0.0.183

nat (inside,outside) static interface service tcp smtp smtp

object network obj-10.0.0.183-01

nat (inside,outside) static interface service tcp https https

object network obj-10.0.0.183-02

nat (inside,outside) static interface service tcp imap4 imap4

object network obj_any

nat (inside,outside) dynamic interface

object network obj_voip

nat (VoIP,outside) dynamic interface

object network BarracudaVPN

nat (inside,outside) static interface service tcp 444 444

object network vpn

nat (inside,outside) static A_64.140.222.185

This was the fix from cisco

!

object network BarracudaVPN

no nat (outside,inside) static interface service tcp 444 444

nat (inside,outside) static interface service tcp 444 444

clear xlate local 10.0.0.12

!

access-list out_in line 1 permit tcp any host 10.0.012 eq 444

!

[Jouni Forss]

Hi,

Do you mean that you need to get on the device that is behind your firewall and you need to access it using the public IP address of the ASA "outside" interface and port TCP/8000?

I dont see any port forward configuration atleast for TCP/8000

The basic configuration to enable TCP/8000 port forwarding would be (provided its supposed to be both the real and the mapped port)

object network

host

nat (inside,outside) static interface service tcp 8000 8000

access-list permit tcp any object

or

access-list permit tcp any host eq 8000

If you meant getting to the device from "inside" interface then I cant really say with the above configuration

Can you clarify the situation a bit if the above things werent correct.

- Jouni

[eferland]

Getting to the device using its internal IP address 10.0.0.12. To access the admin control panel the address is http://10.0.0.12:8000. When I go to that address I get the login in screen but can't login because it can't get out of the firewall via 80.

[Jouni Forss]

Hi,

Could you still clarify as to where the connection attempt to the local IP address of 10.0.0.12 is coming from? From the Internet, from the local LAN or perhaps through VPN connection to the ASA (as I notice you have some sort of NAT0 configuration)

- Jouni

[eferland]

From inside the network 10.0.0.35 (The local LAN)

[Jouni Forss]

Hi,

The traffic inside the same subnet shouldnt even go to the firewall.

One common problem situation where there a LAN subnet is directly connected to the ASA interface is when the ASAs interface has Proxy ARP enabled. It might answer ARP requests for the LAN host trying to access another host on the same subnet and the connection could fail because of this. (Since ASA answers to the ARP request instead of the actual host

Proxy ARP can be disabled with the command

sysopt noproxyarp

But cant really say if this is the case. The firewall shouldnt have anything to do with traffic inside a single subnet

- Jouni

[eferland]

I would agree if it did not work just prior to having made the changes to the ASA to allow outside access via port 444. But accessing the device using 10.0.0.12:8000 worked before making the ASA adjustment for port 444.

[Jouni Forss]

The change that you mention doing is simply switching the source and destination interface for the NAT.

Before the change the NAT would have operated so that

• The translation would have been done for the host 10.0.0.12
• The translation defined that the host 10.0.0.12 was actually behind the "outside" interface and that it would be translated to the "interface" IP address of "inside"
• It would have been accessible from behind the "inside" with TCP/444

After the change the NAT should operate so that

• The translation would still be done for the host 10.0.0.12
• The translation defines that the host 10.0.0.12 is behind the "inside" interface of the ASA and that it would be translated to the "interface" IP address of the "outside"
• It would could be accessed from behind "outside" with TCP/444

Also what I am wondering is that you get a login page? Doesnt this already mean that connectivity to the host exists?

- Jouni

[eferland]

I think you are right I just set up a small network like this;

vpn appliance (10.0.0.12) ------>Switch<-----------laptop (10.0.0.23)

no firewall I get the same outcome.

[eferland]

They are telling me that when I try to login the device goes out to the web to check licensing information. If it can't get out it just spins and times out.

[Jouni Forss]

Hi,

Well if you need to specifically check what the ASA would do to a TCP/80 destination port connection towards the Internet from that local soure IP address you can use "packet-tracer" command

packet-tracer input inside tcp 10.0.0.12 12345 1.1.1.1 80

Just as an example

This should list what rules the ASA applies to the traffic mentioned.

- Jouni

[eferland]

I can't ping

74.125.129.103 from the device

[Jouni Forss]

Hi,

I have no idea what that IP address is supposed to be. The destination for the TCP/80 connection?

ICMP isnt a 100% reliable way to determine that something is working. Its not necesarily allowed everywhere.

The above "packet-tracer" should tell what the ASA would do the TCP/80 traffic.

Naturally something can be told by looking through the ASDM real time monitoring on what happens to the connection from the device to the destination port TCP/80 somewhere.

- Jouni

[eferland]

Result of the command: "packet-tracer input outside icmp 10.0.0.12 8 0 74.125.129.103"

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   10.0.0.0        255.255.255.0   inside

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (rpf-violated) Reverse-path verify failed

[Jouni Forss]

Wrong input interface.

When traffic is coming from host 10.0.0.12 its coming from "inside"

- Jouni