Add a private subnet to existing real class C subnet

Add:

nat (inside) 1 192.168.158.0 255.255.255.0 global (outside) 1 interface route inside 192.168.158.0 255.255.255.0 135.10.158.X

where 135.10.158.X is the IP address of the Procurve.

Note: if your PIX 520 software version is old enough that it does not recognize the word 'interface' in the global command, then a different configuration would have to be used. 'interface' came in about PIX 6.1 or so; for versions before that you would have to use a seperate public IP address for the new traffic.

I don't know the configuration commands for the Procurve line. I see from the HP overview that the 5300 series supports layer 3 switching. So do whatever you need to do on it to add a second subnet,

192.168.158.0/24, and enable routing on the Procurve between the new network and the existing 135.10.158.0/24 network.

Hi Walter, Thank you for replying. I'm still a bit confused on the switch configuration that needs to be done. Assuming that I dedicated a few ports on HP

5304xl switch as Vlan 2 and configure it to use the 192.168.158.0/24 subnet. Don't I need another internal interface on pix to forward outside traffic to the 192.168.158.0/24 subnet (connect another wire from the pix's 2nd internal interface to vlan2)? I don't see how 192.168.158.0/24 (default vlan) and 135.10.158.0/24 (vlan 2) network traffic can be forward to the switch using the same wire.

outside --- pix ---- HP 5304xl --- VLAN1 (135.10.158.0/24) port 1-20 --- VLAN2 (192.168.158.0/24) port 20-40

commands for the Procurve line.

Unless your security situation requires it, you do not need to use different VLANs for different subnets. Just have both subnets run on the same wire between the PIX and the Procurve. The "ip route" statement I gave will instruct the PIX to send traffic destined for 192.168.158.0/24 via the Procurve, which will do the appropriate routing (since it is more than just a Layer 2 switch.)

If you do need different vlans for security reasons [keeping in mind the shared traffic is just on the one wire over to the Procurve], then if you have PIX 6.2 or earlier, then Yes, you would need different physical interfaces. If, though, in this situation you have PIX 6.3 then your PIX 520 will support virtual interfaces, which are 802.1Q Tagged VLANs that share the physical interface (by the magic of the

802.1Q tags.)

Hi Walter, Thank you for your reply. I just have one more question. I have configured VLAN on the procurve switch and added the three statement you suggested. I made one change on the global statement, since I can't use the interface ip for NAT ( I have to use the ip within the class c range that was given by my isp). So my pix config is currently listed below:

ip address outside 135.10.10.5 255.255.255.252 ip address inside 135.10.158.100 255.255.255.0 static (inside,outside) 135.10.158.0 135.10.158.0 netmask 255.255.255.0

0 0 route outside 0.0.0.0 0.0.0.0 135.10.10.2 1 **lines added: nat (inside) 1 192.168.158.0 255.255.255.0 global (outside) 1 135.10.158.254 >configuration

situation requires it, you do not need to use

Your static statement overlaps with your global, because both attempt to control the translation pattern of your external IP

135.10.158.254 . The nat/global pair will be ignored in this case, because plain nat is the lowest priority of the various kinds of address translation.

Unfortunately you did not happen to mention the software version of your PIX 520. If you are running PIX 6.3, then the easiest adjustment would be to use a "policy static": that would involve the creation of an access-list that denied 135.10.158.254 and permitted everything else in 135.10.158/24, and then using

static (inside,outside) 135.10.158.0 access-list POLICY_NAT_ACL

If you are using something before PIX 6.3, then you will have to use a whole series of static statements that together cover the entire range except that they happen to omit 135.10.158.254 . There is a catch to that, though: each time you use a static statement with a netmask other than 255.255.255.255, the PIX assumes you are describing a subnet, and thus that the first and last address in the range are reserved and the PIX assumes that any traffic from those IPs is bogus traffic that should be dropped. You can tell PIX that you really do want traffic on those IPs by adding specific static statements for those IPs, with netmask 255.255.255.255 for them; the PIX will then grumble about overlapping statics on every reboot/reset, but it will do the job.