topic PIX 501 VPN with NAT and same subnets in Network Security

PIX 501 VPN with NAT and same subnets

ngthen — Tue, 12 Mar 2019 01:47:10 GMT

We just aquired a company and they have a older PIX 501 running 6.3(5). This new company is using the same IP address scheme as one of my other VPN tunnels. To make things easier I NAT'd the tunnel to appear to my main firewall as 10.10.12.0/24 rather than 192.168.1.0/24. The VPN is working well and I can get to all of the resources on the other end and they can get into HQ. The problem I am running into is that I cannot SSH, HTTP, Telnet, or ping the inside interface of the PIX. Also from the PIX, I cannot ping an HQ address using ping inside x.x.x.x. I am assuming it is due to the NAT. We have another aquisition with a PIX but the difference with this one is that I can do the noNAT since the IP address scheme is different than anything else we have. I have included my config to see if there is anything I am missing.

PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password ********** encrypted
passwd ********** encrypted
hostname pixfirewall
domain-name company.com
clock timezone EST -5
clock summer-time EDT recurring
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol pptp 1723
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000

fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
name 192.168.1.253 SYSTEM1
name 192.168.1.222 SYSTEM2
name 192.168.1.218 SYSTEM3
name 192.168.1.221 SYSTEM4
name 208.68.91.10 Online_load_tracing
name 172.16.1.230 MANAGEMENT
object-group network HQ-Encrypt
network-object 10.50.1.0 255.255.255.0
network-object 172.16.0.0 255.255.240.0
object-group network NewCompany-Encrypt
network-object 10.10.12.0 255.255.255.0
access-list outside_access_in permit tcp any any eq 3389
access-list outside_access_in permit tcp any any eq pptp
access-list outside_access_in permit udp any any eq isakmp
access-list outside_access_in permit gre any any
access-list outside_access_in permit tcp any interface outside
access-list site1 permit ip 192.168.1.0 255.255.255.0 172.16.0.0 255.255.240.0
access-list site1 permit ip 192.168.1.0 255.255.255.0 10.50.1.0 255.255.255.0
access-list IPSEC-TUN permit ip 10.10.12.0 255.255.255.0 172.16.0.0 255.255.240.0
access-list IPSEC-TUN permit ip 10.10.12.0 255.255.255.0 10.50.1.0 255.255.25.0

pager lines 24
logging on
logging trap notifications
logging host inside SYSTEM2
mtu outside 1500
mtu inside 1500
ip address outside 216.110.239.22 255.255.255.252
ip address inside 192.168.1.254 255.255.255.0
ip verify reverse-path interface outside
ip audit info action alarm
ip audit attack action alarm
ip local pool VPNpool 192.168.100.1-192.168.100.7
pdm location SYSTEM3 255.255.255.255 inside
pdm location SYSTEM1 255.255.255.255 inside
pdm location SYSTEM2 255.255.255.255 inside
pdm location SYSTEM4 255.255.255.255 inside
pdm location Online_load_tracing 255.255.255.255 outside
pdm logging notifications 200
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) tcp interface 3389 SYSTEM1 3389 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface www SYSTEM4 www netmask 255.255.255.255 0 0
static (inside,outside) 10.10.12.0 access-list site1 0 0
access-group outside_access_in in interface outside
route outside 0.0.0.0 0.0.0.0 216.110.239.21 1
timeout xlate 0:05:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
aaa authentication enable console LOCAL
aaa authentication http console LOCAL
aaa authentication ssh console LOCAL
aaa authentication telnet console LOCAL
aaa authorization command LOCAL
http server enable
http 192.168.1.0 255.255.255.0 inside
snmp-server host inside MANAGEMENT
snmp-server community HQ-SNMP
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set HQ esp-aes-256 esp-sha-hmac
crypto map HQ 50 ipsec-isakmp
crypto map HQ 50 match address IPSEC-TUN
crypto map HQ 50 set peer 1.2.3.4
crypto map HQ 50 set transform-set HQ
crypto map HQ 50 set security-association lifetime seconds 3600 kilobytes 65535
crypto map HQ interface outside
isakmp enable outside
isakmp key ********** address 1.2.3.4 netmask 255.255.255.255
isakmp identity address
isakmp policy 50 authentication pre-share
isakmp policy 50 encryption aes-256
isakmp policy 50 hash sha
isakmp policy 50 group 2
isakmp policy 50 lifetime 86400
telnet 192.168.1.0 255.255.255.0 inside
telnet timeout 15
ssh 1.2.3.4 255.255.255.0 outside
ssh 192.168.1.0 255.255.255.0 inside
ssh timeout 15
management-access inside
console timeout 0
dhcpd auto_config outside
username support password ********** encrypted privilege 15
terminal width 80
Cryptochecksum:6b81bcad601b2ea0bcd4d9966cc8d711

PIX 501 VPN with NAT and same subnets

Jouni Forss — Wed, 22 May 2013 16:59:25 GMT

Hi,

I guess the PIX wont accept the management connection if you attempt it to the destination IP address 10.10.12.1 at the moment?

You could always use the "outside" interface to use the management connections.

If you specifically want to run the management connections through the IPsec tunnel then you could consider adding the remote site PIX public IP address to the crypto map ACL.

You would naturally have to add this on both the main site and remote site as mirror images. Main site would also require a NAT0 rule addition that would tell the main site device to NOT NAT the internal hosts when they were attempting to connect to the remote PIX public IP Address and therefore that traffic would get tunneled.

I mean something like this

Remote Site

access-list IPSEC-TUN permit ip host 216.110.239.22 10.50.1.0 255.255.255.0

access-list IPSEC-TUN permit ip host 216.110.239.22 172.16.0.0 255.255.240.0

Main Site

access-list IPSEC-TUN permit ip 10.50.1.0 255.255.255.0 host 216.110.239.22

access-list IPSEC-TUN permit ip 172.16.0.0 255.255.240.0 host 216.110.239.22

access-list INSIDE-NAT0 permit ip 10.50.1.0 255.255.255.0 host 216.110.239.22

access-list INSIDE-NAT0 permit ip 172.16.0.0 255.255.240.0 host 216.110.239.22

nat (inside) 0 access-list INSIDE-NAT0

Naturally the configurations would be different on your actual devices since you have already existing NAT0 ACL and the interface used at the main site for LAN could be something else than "inside"

Hope this helps

- Jouni

PIX 501 VPN with NAT and same subnets

ngthen — Wed, 22 May 2013 17:36:25 GMT

You are correct, if I try to create a management connection the SSH session will fail. The main reason I was wanting to use the tunnel was for SNMP so that I didn't sent it over the Internet. However anything I try on the PIX even ping inside 172.16.1.230 fails. If I ping the same from a workstation on the other end, it works.

PIX 501 VPN with NAT and same subnets

Jouni Forss — Wed, 22 May 2013 17:40:18 GMT

Hi,

The above changes in the Encryption Domain and the NAT configuration also apply to using SNMP to the PIX through the L2L VPN. This I have tested personally.

You could for example use SNMP and send Syslog from the PIX by simply stating in the configuration that "outside" interface was used. For example with the logging the PIX would then use the "outside" interface IP address as the source of the Syslogs sent to the server and if we had the previously suggest ACL configurations, then it should be possible to run all that traffic through the protected L2L VPN Connection.

- Jouni

PIX 501 VPN with NAT and same subnets

ngthen — Wed, 22 May 2013 20:36:02 GMT

So you are suggesting that I add the following in addition to the existing lines in the IPSEC-TUN acl?

access-list IPSEC-TUN permit ip host 216.110.239.22 10.50.1.0 255.255.255.0

access-list IPSEC-TUN permit ip host 216.110.239.22 172.16.0.0 255.255.240.0

The remote site has WWW published using the 216.110.239.22. Would this traffic now go through the tunnel as well? No big deal, just checking.

PIX 501 VPN with NAT and same subnets

Jouni Forss — Wed, 22 May 2013 21:24:16 GMT

Hi,

To my understanding it would work so that when the 2 private networks at the main site would be connection to the host IP address of 216.110.239.22 THEN all traffic would be going through the L2L VPN connection.

You would just have to mirror the mentioned VPN ACL rules jon the main site ust like the current existing VPN ACLs rules and on the main site you would need the NAT0 between the main site LAN networks and the remote site public IP address.

Naturally this wouldnt affect any other traffic from the Internet to the mentioned public IP address and the WWW server using it.

- Jouni