12-30-2011 06:49 AM - edited 03-11-2019 03:08 PM
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.
12-30-2011 07:15 AM
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
12-30-2011 08:59 AM
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
12-30-2011 11:15 AM
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.
12-30-2011 01:48 PM
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
12-30-2011 02:50 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide