SSH to DMZ IP gives Deny IP Spoof

[mo shea]

Hi,

We have a client who nats his public IP  (static nat) located on the outside to an HTTP Proxy for users to access Internet. Now when he try's to ssh from outside to manage this 5520 ASA he is never successful since the outside interface is natted to this proxy server.

I suggest if he could use another interface and staticly NAT its IP to another public IP from the subnet allocated to his company.

While the client is taking his time to free up an interface on his ASA, I set up a similar scenario but on GNS3 to test connectivity, but whenever I try to ssh from an outside ssh client to the DMZ interface, I get

Deny IP spoof from (ssh client IP) to (Public IP nated to DMZ physicla IP) on interface outside.

I have a static route outside on the firewall and I tested connectivity to the inside network by doing RDP on a windows client located on the inside.

I just want to know is such a configuration workable, or is there any limitation using a simulator?

IP Addresses

outside IP = 193.193.193.1  (not real IPs)

dmz IP = 192.168.2.1

inside IP = 192.168.1.1

inside client IP = 192.168.1.10

Router connected to ASA Outside IP = 193.193.193.10

Router interface connected to client (simulating internet user) IP = 194.194.194.1

Internet User IP (connected to Router int) = 194.194.194.10

Relevent config

static (dmz,outside) 193.193.193.5 192.168.2.1 netmask 255.255.255.255

static (inside,outside) interface 192.168.1.10 netmask 255.255.255.255

access-list outside_in extended permit ip any host 193.193.193.5

access-list outside_in extended permit ip any host 193.193.193.1

route outside 0.0.0.0 0.0.0.0 193.193.193.10

All help is appreciated

Regards

Mo Shea

[Marcin Latosiewicz]

If I understand what is the end goal you're trying to achieve, which I would sum up as "communicate with interface B when initiating traffic from something off interface A" .  then I can tell you it's not supported and never was on ASA/PIX or FWSM.

Possible workaround would be to use IPsec/SSL VPN and management-interface command.

[mo shea]

Thanks for your response,

I thought since it was possible to directly initiate connections with DMZ servers when their ips are natted to some public IP, why  not to initiate contact directly with the DMZ physical interface itself if its ip is natted to a public one?

[Marcin Latosiewicz]

Simplest answer is that to-the-box and through-the-box traffic is treated differently :-)

I think if you do not NAT and run same test from inside and dmz (or other way around) you should get similar message and same result.

[m.kafka]

Do not try to ssh to the DMZ interface, especially not to a translated address of the DMZ interface. Establish an ssh session the outside instead.

Do not use a static if 192.168.1.10 on the inside if you need to establish connections to the outside (I assume you dont need to accept inbound connections from the internet).

if it is just about outbound connections I recommend to use a nat/global:

nat (inside) 1 192.168.1.10 255.255.255.255

global (outside) 1 interface

this will allow only the proxy to establish outbound connections and the outside interface can accept ssh sessions (as long as you have a configuration similar to "shh {ip-address} {mask} outside" - please substitute address/mask to suit your needs.

[mo shea]

Thanks for the responses. Unfortunately I need to static nat the inside interface since this proxy publishes email server as well. I will look into using the management command, and if I face any difficulties (hopefully not) will post in another thread.

Thanks again

[m.kafka]

tacobell wrote:
Thanks for the responses. Unfortunately I need to static nat the inside interface since this proxy publishes email server as well. I will look into using the management command, and if I face any difficulties (hopefully not) will post in another thread.
Thanks again

Leave the nat/global like I suggested.

If you need inbound SMTP additionally to outbound NAT for HTTP-proxy then use a port-static:

static (inside,outside) tcp interface 25 192.168.1.10 25

This will translate only inbound tcp/25 to the inside server, port 22 will be free for accepting ssh.

hope that helps

[mo shea]

Thanks for the very helpful tip. I was also thinking of asking the client if he could static NAT the inside to a different public IP other than the outside interface one, but that required changing their routing and probably some downtime. But I will try your suggestion in the lab and see how it goes.

Thanks again