topic How would you solve this access issue in Network Security

How would you solve this access issue

charlie.ford — Mon, 11 Mar 2019 22:08:44 GMT

Current translations is an established stable network translation:

static (inside,outside) 10.144.158.7 192.168.100.20

access-list allows port 80

While maintaining the above translation we have been ask by the developers to allow direct access to 192.168.100.20 for a secure socket connection on port 443. I did a similar thing during a data center migration by doing this.

static (inside,outside) 192.168.100.0 192.168.100.0 netmask 255.255.255.0

static (inside,outside) 10.144.158.7 192.168.100.20 netmask 255.255.255.255

This configuration was in place for months with out issue.

client connecting to 192.168.100.20 connected to 192.168.100.20

client connecting to 10.144.158.7 connected to 192.168.100.20

As long as the order of the static table is maintained the firewall will allow it to be configured.

My first question would be, how would you have done it?

My ultimate question will be, with details to follow if you are interested, why it would periodically fail when applied to a well established VPN L2L tunnel configuration.

How would you solve this access issue

ajay chauhan — Fri, 30 Dec 2011 15:15:29 GMT

This explaination makes me little bit confused . Can you post me the full config also mentioned where is the source and destination and what results you want to get.

Thanks

Ajay

Re: How would you solve this access issue

charlie.ford — Fri, 30 Dec 2011 16:59:07 GMT

The configurations no longer exist but I can recreate them in the lab for you.

Trying to find a better way to explain.

Customer on outside interface needs to get to 192.168.100.20 and has been doing so for years. They use the static translation 205.144.158.7 to connect to 192.168.100.20.

It has become necessary to grant the customer on the outside interface direct access to 192.168.100.20 without translation while still allowing them access through the original static translation.

So the customer on the outside interface will be accessing both the new 192.168.100.20 and the old 205.144.158.7 but connecting to the same internal server 192.168.100.20. It works, I have done it but is there a better way?

access-list outside line 1 extended permit icmp any host 205.144.158.7 (hitcnt=0) 0xf4592732

access-list outside line 2 extended permit tcp any host 205.144.158.7 eq www (hitcnt=3) 0xe2670b47

access-list outside line 3 extended permit tcp any host 205.144.158.7 eq https (hitcnt=1) 0x6b2d9f98

access-list outside line 4 extended permit icmp any host 192.168.100.20 (hitcnt=0) 0x8ab9d8f4

access-list outside line 5 extended permit tcp any host 192.168.100.20 eq www (hitcnt=1) 0xc67c07f6

access-list outside line 6 extended permit tcp any host 192.168.100.20 eq https (hitcnt=1) 0x7675a5b1

This passes the packet-tracer

Thanks for your response. Lab configuration attached.

Charlie

402-963-8295

How would you solve this access issue

ajay chauhan — Fri, 30 Dec 2011 19:15:10 GMT

In LAB you can route your packets from Public to Private IP but in real world 192.168.x.x is private IP and not routed over internet.

So only way to connect would be NATTED IP and if you want to access on 192.168.x.x then VPN solution. No other way.

Re: How would you solve this access issue

charlie.ford — Fri, 30 Dec 2011 21:48:06 GMT

I apologize for not making myself clear.

This is a privet circuit in the lab environment, would it be helpful if I gave you the real addresses? Or can you pretend the Customer network is trusted and routed to the gateway firewall where this configuration exists? No Internet, just customer to customer, like through a VPN tunnel?

If I am not making this clear please let me know and I will try again. I really need to solve this problem without using another firewall.

Charlie

402-963-8295

Re: How would you solve this access issue

Julio Carvajal — Fri, 30 Dec 2011 22:50:34 GMT

Hello Charlie,

What Ajay has mentioned is correct, now as you said on the last note :

No Internet, just customer to customer, like through a VPN tunnel

If you only need connectivity between both sides without internet you do not need a routable public ip address, now you are going to use Identity nat and also a static one to one, both are going to work.

The ASA wil be able to send the packets that are getting to 205.144.158.7 to the inside host, and also with proxy arp the identity nat statement (192.168.100.20).

You already have the ACLs in place, that is all you need as long as Ajay said they do not need to access 192.168.100.20 by the real IP address over the internet (unless you have a VPN established)

Regards,

Julio