Access-list question

I have some small remote offices with 2 office machines and 2 public machines(anyone outside company can use them). I am going to install 501 for each remote office to make a VPN connection to 515 at the head office. What I plan to do is to block 2 pulic machines of accessing to head office resources. here are my settings: The public machines should have only access to Internet

access-list 102 permit ip 192.168.102.21 255.255.255.255 10.10.0.0

255.255.0.0 -->domain machine access-list 102 permit ip 192.168.102.22 255.255.255.255 10.10.0.0 255.255.0.0 ->domain machine access-list 102 permit ip 192.168.102.20 255.255.255.255 10.10.0.0 255.255.0.0 --> ->domain machine access-list 102 deny ip 192.168.102.0 255.255.255.0 10.10.0.0 255.255.0.0 --> block any other machine including those publics

nat (inside) 0 access-list 102 nat (inside) 1 0.0.0.0 0.0.0.0 0 0 global (outside) 1 interface

So am I doing right config?

Another question using DHCPD, can I reserve a specific IP for a mac address?

Thanks a lot for any help-Rob

Reply to
Rob
Loading thread data ...

I presume you are talking about the DHCP server in IOS.

Yes, you can manually bind IP addresses to mac addresses. What you need to do is create a separate pool for that particular host. For example

ip dhcp pool testhost host 192.168.1.23 hardware-address 2222.2222.2222

Since attributes are inherited, this host-specific pool will inherit other attributes from the more general pool for this network.

Take a look at

formatting link
Cisco da Gama
formatting link

Reply to
ciscodagama

-->domain machine

You can use "host 192.168.102.21" instead of "192.168.102.21 255.255.255.255". The PIX will automatically convert the form with the netmask into the "host" form.

->domain machine

--> ->domain machine

block any other machine including those publics

access-lists have an implicit "deny" at the end of them, so that last statement is redundant.

We can't be sure from that.

The traffic that the VPN tunnel is willing to carry is determined by the crypto map "match address" ACL. That ACL is examined -after- translation would take place. nat 0 access-list causes the translation phase to leave the matched traffic alone. If the crypto map "match address" ACL is written in terms if 192.168.102.* to 10.10.*.* then Yes, the traffic that did not match the ACL would not be able to go over the VPN -- as sort of a third-order effect.

There are two other important ways to prevent traffic from going over a VPN. The most obvious way is to not permit the traffic in the crypto map "match address" ACL that defines the tunnel.

Slightly more obscure is to *not* use "sysopt connection permit-ipsec" and to deny the traffic in your interface ACLs. If that sysopt is

*not* there, then the interface ACLs have to be satisfied before the traffic is permitted to be sent to the VPN tunnel. You could deny the traffic in an access-list applied via an "access-group" command to your inside interface.

So, that's three ways: don't permit the traffic through the interface; don't permit the traffic through the tunnel; or have the traffic translated (or exempted from translation) so that it does not match the tunnel definition.

No, not in any PIX software version that will run on the 501. I haven't seen this feature for later PIX software versions that run on higher-end models, but I have not really had much chance to go over those versions in detail.

Reply to
Walter Roberson

I'm not sure why you would presume that. The OP specifically indicated PIX 501, which has its own dhcpd (which does not allow any kind of reservation.)

Reply to
Walter Roberson

I have some remote sales offices set up with 501's and wireless in the offices. I actually leave all outbound access open and install VPN clients on the individual machines. That way DHCP does not play a role and I can associate the mac address of the VPN client machines with an ACL on the subinterface I use for inbound VPN traffic.

This allows out customer/guests to use our wireless and I can secure all communications from our employees.

Reply to
notkailen

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.