Solved

PIX IOS 7.X Site-to-Site VPN question

Posted on 2006-06-12
7
901 Views
Last Modified: 2013-11-16
Hi,

I have configured site-to-site VPN tunnels on a PIX but our vendor has made the following requirement to establish a VPN tunnel - they expect all traffic from my end to come from the following IP only -10.97.212.68 (not a part of our network). Can somebody help me with the syntax required for this configuration, please.

IP for Traffic from mycompany
10.97.212.68/32

IP for Traffic to myvendor
10.96.175.201/32
10.96.175.202/32
10.40.20.201/32
10.40.16.87/32
10.40.24.15/32
10.40.24.16/32
10.40.16.156/32

Key: abckey
\
**************************************************************************************
PIX Version 7.2(1)
!
hostname mycompany-PIX515E
domain-name mycompany.local
names
dns-guard
!
interface Ethernet0
 nameif outside
 security-level 0
 ip address 192.168.2.2 255.255.255.0
!
interface Ethernet1
 nameif inside
 security-level 100
 ip address 192.168.0.254 255.255.255.0
!
interface Ethernet2
 nameif dmz
 security-level 50
 ip address 192.168.1.1 255.255.255.0
!
boot system flash:/image
ftp mode passive
clock timezone CST -6
clock summer-time CDT recurring
dns server-group DefaultDNS
 domain-name mycompany.local
access-list outside-in extended permit icmp any any
access-list outside-in extended permit tcp any host 192.168.0.2 eq www
access-list outside-in extended permit tcp any host 192.168.0.2 eq 3389
access-list outside-in extended permit tcp any host 192.168.0.2 eq https
access-list outside-in extended permit tcp 64.18.0.0 255.255.240.0 host 192.168.0.2 eq smtp
access-list outside-in extended permit tcp any host 192.168.0.10 eq www
access-list outside-in extended permit tcp any host 192.168.0.10 eq https
access-list outside-in extended permit tcp any host 192.168.1.2 eq www
access-list outside-in extended permit tcp any host 192.168.1.2 eq 8080
access-list outside-in extended permit tcp any host 192.168.1.2 eq https
access-list outside-in extended permit tcp any host 192.168.1.3 eq www
access-list outside-in extended permit tcp any host 192.168.1.3 eq 8080
access-list outside-in extended permit tcp any host 192.168.1.3 eq https
access-list outside-in extended permit tcp any host 192.168.1.4 eq www
access-list outside-in extended permit tcp any host 192.168.1.4 eq 8080
access-list outside-in extended permit tcp any host 192.168.1.4 eq https
access-list dmz-in extended permit tcp host 192.168.1.2 any eq www
access-list dmz-in extended permit tcp host 192.168.1.2 any eq https
access-list dmz-in extended permit tcp host 192.168.1.2 eq www any
access-list dmz-in extended permit tcp host 192.168.1.2 eq https any
access-list dmz-in extended permit icmp 192.168.1.0 255.255.255.0 192.168.0.0 255.255.255.0 echo-reply
access-list dmz-in extended permit udp host 192.168.1.2 any eq domain
access-list dmz-in extended permit tcp host 192.168.1.2 any eq 8080
access-list dmz-in extended permit tcp host 192.168.1.2 eq 8080 any
access-list dmz-in extended permit tcp host 192.168.1.2 any eq 1433
access-list dmz-in extended permit tcp host 192.168.1.2 eq 1433 any
access-list dmz-in extended permit icmp any any
access-list nonat extended permit ip 192.168.0.0 255.255.0.0 any
pager lines 24
logging asdm informational
mtu outside 1500
mtu inside 1500
mtu dmz 1500
asdm image flash:/asdm521.bin
asdm history enable
arp timeout 14400
nat-control
nat (inside) 0 access-list nonat
static (inside,dmz) 192.168.0.0 192.168.0.0 netmask 255.255.255.0
static (inside,outside) 192.168.0.2 192.168.0.2 netmask 255.255.255.255
static (inside,outside) 192.168.0.10 192.168.0.10 netmask 255.255.255.255
static (dmz,outside) 192.168.1.2 192.168.1.2 netmask 255.255.255.255
static (dmz,outside) 192.168.1.3 192.168.1.3 netmask 255.255.255.255
static (dmz,outside) 192.168.1.4 192.168.1.4 netmask 255.255.255.255
access-group outside-in in interface outside
access-group dmz-in in interface dmz
route outside 0.0.0.0 0.0.0.0 192.168.2.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa authentication telnet console LOCAL
aaa authentication ssh console LOCAL
aaa authentication enable console LOCAL
no snmp-server location
no snmp-server contact
snmp-server community public
snmp-server enable traps snmp authentication linkup linkdown coldstart
no sysopt connection permit-vpn
telnet 192.168.0.0 255.255.255.0 inside
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 5
ssh version 1
console timeout 0
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns migrated_dns_map_1
 parameters
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns migrated_dns_map_1
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect http
  inspect netbios
  inspect rsh
  inspect rtsp
  inspect skinny
  inspect esmtp
  inspect sqlnet
  inspect sunrpc
  inspect tftp
  inspect sip
  inspect xdmcp
!
service-policy global_policy global
prompt hostname context
: end
[OK]
mycompany-PIX515E#
**************************************************************************************
0
Comment
Question by:netman70
  • 4
  • 3
7 Comments
 
LVL 9

Expert Comment

by:stressedout2004
Comment Utility
A couple of questions:

1) Will the VPN terminate on the PIX above or to another PIX?
2) I noticed that the PIX above does not have a public IP, I am assuming that NAT for internet access is being done somewhere else, correct?
0
 

Author Comment

by:netman70
Comment Utility
1) Will the VPN terminate on the PIX above or to another PIX?

VPN tunnel is between the PIX above and a CheckPoint VPN endpoint at the remote end,.

2) I noticed that the PIX above does not have a public IP, I am assuming that NAT for internet access is being done somewhere else, correct?

NAT for internet access is being done by a Radware LinkProof branch internet redundancy device.

Thank for your help
0
 
LVL 9

Expert Comment

by:stressedout2004
Comment Utility
Here's the thing, in order for your network to appear to be coming from 10.97.212.68/32 when communicating to your vendor, you will need to implement policy NAT. In your case, you will have to switch the firewal NAT mode to no nat-control. Which means you have to reconfigure your entire NAT. The configuration below is what you need and they need to be enter in the order that they appear.

The following variables were used:

1) 1.1.1.1 is the Checkpoint public IP
2) abckey was used as a preshared key

Additional requirements:

- You need one is to one static NAT for the PIX external IP (192.168.2.2) on Radware.

If you have any questions on the configuration below let me know.

clear configure nat
clear configure static
no nat-control

access-list match_acl permit ip host 10.97.212.68 host 10.96.175.201
access-list match_acl permit ip host 10.97.212.68 host 10.96.175.202
access-list match_acl permit ip host 10.97.212.68 host 10.40.20.201
access-list match_acl permit ip host 10.97.212.68 host 10.40.16.87
access-list match_acl permit ip host 10.97.212.68 host 10.40.24.15
access-list match_acl permit ip host 10.97.212.68 host 10.40.24.16
access-list match_acl permit ip host 10.97.212.68 host 10.40.16.156

access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.96.175.201
access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.96.175.202
access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.40.20.201
access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.40.16.87
access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.40.24.15
access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.40.24.16
access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.40.16.156

global (outside) 1 10.97.212.68
nat (inside) 1 access-list vpn_nat

crypto ipsec transform-set 3DES esp-3des esp-md5-hmac

crypto map to_vendor 10 match address match_acl
crypto map to_vendor 10 set peer 1.1.1.1
crypto map to_vendor 10 set transform-set 3DES
crypto map to_vendor interface outside

isakmp identity address
isakmp enable outside

isakmp policy 1 authentication pre-share
isakmp policy 1 encryption 3des
isakmp policy 1 hash md5
isakmp policy 1 group 2
isakmp policy 1 lifetime 86400

tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
pre-shared-key abckey
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 

Author Comment

by:netman70
Comment Utility
Thanks for your help stressedout2004.

1. When 'no nat-control' is enabled, does all my existing static mapping go away, along with the 'nat (inside) 0 access-list nonat' statement?

2. Do my existing access list remain the same? Will anything else change?

I have one-to-one NAT configured on the radware for all the servers and the PIX. I also have dynamic NAT setup for the (internal) 192.168.0.X subnet.

Thanks again.
0
 
LVL 9

Accepted Solution

by:
stressedout2004 earned 500 total points
Comment Utility

1. When 'no nat-control' is enabled, does all my existing static mapping go away, along with the 'nat (inside) 0 access-list nonat' statement?

>>>> No, not unless you remove them. But the thing is we **need** to remove all of your static mapping and NAT 0. Noticed the first two commands I gave you:

clear configure nat
clear configure static

These commands will remove *all* your NAT and static statements. The reason we need to remove those statement is because of the order of precedence. NAT 0 is implemented first, then static, followed by policy NAT and lastly regular NAT and PAT. Because of the way you have your NAT/Static configured, we will never get the policy NAT to work which is the only solution to your dilemma.

If you look at your NAT and static, the IP doesn't change. For instance, when 192.168.0.2 goes outside, it still is 192.168.0.2, the real translation takes place on the Radware where 192.168.0.2 gets translated to a public IP.
There is really no *real* translation taking place on the PIX but a mere compliance of the working principles of the PIX
wherein all traffic traversing it must have either a NAT or Static rule.

This is where no nat-control comes in the picture. With no nat-control enable, the PIX will no longer require a NAT or a static  translation for traffic to be allowed through, however you still need the access-rule for outside to inside communication and ASA still applies. Just because you have no nat-control however doesn't mean you can't have NAT. You can combine both. So in your case NAT will be applied  for the 192.168.0.0 so they get translated to 10.97.212.68 but if and only if the traffic is destined to the your vendor's IPs.  If the traffic is destined to the internet then there will be no need for translation. Now as for the servers that needs to be accessible from the internet, by virtue of the no nat-control, you will no longer need a static mapping for it. Traffic from the internet will be allowed as long as there is an access-list configured allowing the traffic.


2. Do my existing access list remain the same? Will anything else change?

Yup, all access-rules remains the same. It's just the NAT that needs to change.

P.s Please take note that since your vendor requested that traffic from your internal network appears to be coming from
a single IP, the flow of traffic will be one way. Meaning, you will be able to access your vendors network, but your vendor will not be able to access yours.

0
 

Author Comment

by:netman70
Comment Utility
Thanks a million, stressedout2004. I giving you the points but if you could explain the difference between using 'no nat-control' and 'firewall transparent'.

Thanks for your help.
0
 
LVL 9

Expert Comment

by:stressedout2004
Comment Utility
Firewall transparent is way way way different from no nat-control. The no nat-control dictates how PIX should process packet with "no matching translation" and still consults the routing table on where to send the packet to. The firewall transparent on the other hand, acts like a layer 2 firewall and allows you to add a firewall without any change on the IP structure however it can't be use as a default next hop for the internet and doesn't support NAT. When a PIX is in transparent mode, all it does pretty much is filter Layer 3 traffic. It doesn't do NAT, it doesn't do VPN for traffic that is meant to pass through it, it doesn't support dynamic routing etc... Of course it can do other stuff like DHCP server, pass ether type traffic etc.

e.g.

Supposing you have the following topology:

-------192.168.2.0/24 (internal LAN)-------(2.1)-Radware--(1.1.1.1)--------internet

If you introduced the PIX in routed mode, you would have the following:

--192.168.2.0/24 (internal LAN)-------(2.1)-PIX-(192.168.1.2)-----(1.1)-Radware--(1.1.1.1)--------internet

As you noticed you have to restructure the IP addressing and make way for another subnet between the PIX and the Radware. The default gateway of the internal LAN changes to the PIX instead of the Radware.

In Firewall Transparent mode, you would have:


--192.168.2.0/24 (internal LAN)--------PIX------(2.1)-Radware--(1.1.1.1)--------internet
                                                      (2.2)

The default gateway of the internal LAN will still be the Radware and not the PIX. And as you noticed PIX is assigned only one IP called the management IP that is *within* the internal network and you don't have to restructure the IP.
You still connect the inside interface to the internal LAN and the outside interface to the Radware but you don't give each interface an IP, only management IP. In this scenario, when PIX needs to route traffic, it doesn't lookup its routing table, rather it looks at its ARP table. ASA still applies, return traffic originated from the inside will be allowed without any access rules but traffic from the outside will need to be permitted.

Transparent mode won't help you in your case, you won't be able to terminate the VPN on the PIX.





0

Featured Post

What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

Join & Write a Comment

Suggested Solutions

This is about downgrading PIX Version 8.0(4) & ASDM 6.1(5) to PIX 7.2(4) and ASDM 5.2(4) but with only 64MB RAM and 16MB flash. Background: You have a Cisco Pix 515E which was running on PIX 7.2(4) and its supporting ASDM 5.2(4) without any i…
When I upgraded my ASA 8.2 to 8.3, I realized that my nonat statement was failing!   The log showed the following error:     %ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows It was caused by the config upgrade, because t…
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…
This video shows how to remove a single email address from the Outlook 2010 Auto Suggestion memory. NOTE: For Outlook 2016 and 2013 perform the exact same steps. Open a new email: Click the New email button in Outlook. Start typing the address: …

771 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now