6

TL/DR

I set up a static nat rule, so that I can use my public internet IP address to directly ssh into a dedicated machine on the inside network. As a result I cannot ssh into the dedicated machine anymore, when connected through AnyConnect VPN. Why? How do I fix this?

Long story:

I have an ASA 5512-X which I use to terminate AnyConnect VPN sessions. This has been working very well. People use AnyConnect to connect to the ASA, the get IP addresses from the specially assigned IP pool and they can access everything I put in the access-lists.

Now, I have this idea to directly forward port 22 to a dedicated machine in my network (I only have inside and outside interfaces), so that I can SSH into my public IP address and end up on the dedicated machine, without the requirement for a VPN connection.

The setup seemed simple enough:

object network MyEndpoint
    host 10.0.0.1
    nat (inside, outside) static interface service tcp ssh ssh
access-list from_outside_inside extended permit tcp any object MyEndpoint eq ssh
access-group from_outside_inside in interface outside

and it actually works. Now I can

ssh ssh.mydomain.com

and actually get a ssh session on my dedicated machine. However, this success comes at the cost that ssh 10.0.0.1 does not work anymore when I am connected to my ASA/network through AnyConnect as it used to, before I set up static NAT.

I can deterministically control the ASA's behaviour:

When I don't have the nat (inside,outside) line in my configuration,

  • ssh 10.0.0.1 works but
  • ssh ssh.mydomain.com does not work.

When I have the nat (inside,outside) rule as part of the configuration, it is the other way round:

  • ssh ssh.mydomain.com works but
  • ssh 10.0.0.1 does not work.

To investigate I set up a capture on the ASA

capture MyEndpoint type raw-data interface inside
capture MyEndpoint type raw-data interface outside
capture MyEndpoint match tcp host 10.0.0.1 any

When I first connect via AnyConnect and then try to ssh 10.0.0.1, the capture doesn't show/capture anything, as long as the nat (inside,outside) rule is active. Also, my SSH connect attempts never reach the server.

Clearly the ASA is eating the connection requests originating from AnyConnect-connected endpoints, when the nat rule is active.

At first I thought I require some addition to the access-list, but I couldn't make it work that way. On which interface does VPN traffic enter the ASA anyway? outside or inside? I suppose in this case doesn't matter, because I am using a wildcard (any) for the source, which, in my oppinion, includes VPN traffic as well.

Then I thought the ASA would always apply the nat, which means the packet carrying the SYN-ACK would be natted to my outside IP which breaks the connection, as I am connecting from a private VPN address, not the Internet. But the SYNs never get to the server, hence there are no SYN-ACKs.

I spent all day warpping my head around the "new" nat command. When I do a show nat on my ASA I get

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static MyEndpoint interface   service tcp ssh ssh 
    translate_hits = 0, untranslate_hits = 0

As far as I got today this only does a source address translation for leaving traffic. I have no idea, how/why this implies a destination address translation for traffic originating from the Internet arriving at the ASA. Can anybody explain to me why the ASA is behaving this way?

Edit 1: packet-tracer

Reading on through the documentations I came accross the ASA command packet-tracer. When I do

packet-tracer input inside tcp 10.100.0.2 31337 10.0.0.1 22

The ASA tells me a flow would be created and the packet accepted. When I do

packet-tracer input outside tcp 10.100.0.2 31337 10.0.0.1 22

I get

Phase: 6
Type: WEBVPN-SVC
Subtype: in
Result: DROP
Config:
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

So I guess this is some implicitly wanted behaviour, except if you are me.

Edit 2: Searching for hairpins

I found some articles which eventually pointed me to this promissing one which held the information I might need a nat rule along the lines of

nat (outside,outside) \
    source static \
        client_vpn_pool client_vpn_pool \
    destination static \
        remote_office_net remote_office_net

but it didn't work. I have a network object for my vpn client subnet and a network object for the subnet of 10.0.0.1. Adapting the template above did not yield the expected result.

When my nat (inside,outside) rule is in place, SSH does not work, but I can ping 10.0.0.1 just fine. When I add a nat (outside,ouside) rule as suggested by the article, the ping stops working. I also tried versions of the outside-ouside rule with network objects for the specific host and just the range of the ip local pool used for vpn clients. They all just make the ping stop.

Edit 3: Never mind

It's working now. I literally didn't change anything. I just went to bed. I guess there was some internal state in the ASA that caused this behaviour and it timed out while I was asleep.

There is still the thing that when I use packet-tracer input [inside|outside] tcp <my vpn ip> 31337 10.0.0.1 22 packet-tracer always says the packet would be dropped.

When I put packet-tracer input inside it fails at:

Phase: 6
Type: WEBVPN-SVC
Subtype: in
Result: DROP
Config:
Additional Information:

[...]
Drop-reason: (acl-drop) Flow is denied by configured rule

and when I put packet-tracer input outside it fails at:

Phase: 6
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
object network MyEndpoint
 nat (inside,outside) static interface service tcp ssh ssh 
Additional Information:

[...]
Drop-reason: (acl-drop) Flow is denied by configured rule

Yet, as of today, ping and SSH to/from my VPN-connected Laptop to MyEndpoint (a.k.a. 10.0.0.1) works like a charm. How does this ASA thing work???

closed as too broad by Ron Maupin Nov 25 '18 at 17:23

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Hi, can you go online in Chat? I have the Same ASA and it would be nice to talk about it, but not in this Thread because this is offtopic ;-) Would be very nice ! – SystemCookie Feb 7 '17 at 10:17
  • Is it? I was wondering if Superuser might have been the better place, but there we mostly discuss operating systems and this site has so many questions about ASAs ... I would like to talk about it, but I really can't. May I message you in a couple of days? – user1129682 Feb 7 '17 at 10:22
  • No, your post is completely correct. I mean chatting in a question is offtopic ;-) Yes you can message me - if you click on chat, I'll send you the data where you can find me and we can nerd talk about ASA 5512-X ;-) – SystemCookie Feb 7 '17 at 10:27
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 16 '17 at 21:56
  • "It's working now. I literally didn't change anything. I just went to bed. I guess there was some internal state in the ASA that caused this behaviour and it timed out while I was asleep." Please post this as an answer and accept it so that the question doesn't keep popping up forever, looking for an answer. – Ron Maupin Nov 25 '18 at 5:17
0

So, if I understand correctly you can't access the inside interface of your ASA via SSH when connected via VPN? Have you tried issuing the following command on the ASA:

management-access inside

If your VPN tunnel terminates on one interface, but you want to manage the ASA by accessing a different interface, you need to identify that interface as a management-access interface.

  • No, there is nothing wrong with accessing the ASA. When connected via VPN, I cannot ssh into the Linux server (let's call him Rudolph) that is part of my inside network and I set up the static NAT for. Everything else works great. I can ssh into Rudolph from any other computer on the inside network. I can ssh into Rudolph from the Internet. But I cannot ssh into Rudolph when connected via VPN. However, I can ping Rudolph when connected via VPN. I also have management-access inside set. – user1129682 Feb 7 '17 at 8:27
  • @user1129682, it sounds like you just need to allow SSH on the VPN. Just modify the ASA configuration to allow SSH from the tunnel interface to the inside interface. – Ron Maupin Feb 7 '17 at 14:21
  • @RonMaupin what is the tunnel interface? (pointers to doc are fine for me) – user1129682 Feb 7 '17 at 14:50
  • @user1129682, That is what you created for your VPN on the ASA. – Ron Maupin Feb 7 '17 at 15:28
  • @RonMaupin I didn't. I found the box in its current state and nobody is willing to even claim that the people who set it up even ever existed. But apparently the ASA is in productive use ... Do you mean the interface that webvpn is enabled on? I have enabled outside and enabled inside. Also, it is working now (see Edit 3) without any further configuration. – user1129682 Feb 7 '17 at 16:03
0

Please be informed that while accessing web based SSL VPN, the NAT and PAT are restricted in CISCO ASA. Also, the traffic flow must be specified using bi-directional ACLs, by allowing return connections from a lower security host to a higher security host even if there is already an established connection from the higher level host to the lower level host (Not stateful anymore).

Hope this is the reason for your configured NAT didn't work.

The command "sysopt connection permit-vpn" is used in the ASA to allow the VPN traffic regardless of access-lists (exempted policy by allowing entire VPN traffic), however you can use the VPN filters and policies for restricting the traffic.

Assuming the command is active on your firewall and the dns-server value attribute is not properly configured on your VPN policies.

Glad to see that it worked for you without any changes.

Not the answer you're looking for? Browse other questions tagged or ask your own question.