Trying to block access from "inside" to "dmz1"...
interface Ethernet0/1 nameif inside security-level 100 ip address 192.168.1.1 255.255.255.0 ! interface Ethernet0/2 nameif dmz1 security-level 2 ip address 192.168.2.1 255.255.255.0 ! access-list acl_outgoing extended deny ip any 192.168.2.0
255.255.255.0 access-list acl_outgoing extended permit ip any any ! access-group acl_outgoing in interface insideWhy am I still able to access host 192.168.2.2 from 192.168.1.7 ??
That should be 0.0.0.255.
Your ACL blocks access to X.X.X.0, not 192.168.2.X, because you used a netmask instead of a wildcard mask.
Hello, PL!
P> interface Ethernet0/1 P> nameif inside P> security-level 100 P> ip address 192.168.1.1 255.255.255.0 P> ! P> interface Ethernet0/2 P> nameif dmz1 P> security-level 2 P> ip address 192.168.2.1 255.255.255.0 P> ! P> access-list acl_outgoing extended deny ip any 192.168.2.0 P> 255.255.255.0 P> access-list acl_outgoing extended permit ip any any P> ! P> access-group acl_outgoing in interface inside
ASA ?
Hello, Barry!
??>> Trying to block access from "inside" to "dmz1"... ??>>
??>> interface Ethernet0/1 ??>> nameif inside ??>> security-level 100 ??>> ip address 192.168.1.1 255.255.255.0 ??>> ! ??>> interface Ethernet0/2 ??>> nameif dmz1 ??>> security-level 2 ??>> ip address 192.168.2.1 255.255.255.0 ??>> ! ??>> access-list acl_outgoing extended deny ip any 192.168.2.0 ??>> 255.255.255.0
BM> That should be 0.0.0.255.
??>> access-list acl_outgoing extended permit ip any any ??>> ! ??>> access-group acl_outgoing in interface inside ??>>
??>> Why am I still able to access host 192.168.2.2 from 192.168.1.7 ??
BM> Your ACL blocks access to X.X.X.0, not 192.168.2.X, because you used a BM> netmask instead of a wildcard mask.
asa5510(config)# access-list FromOutside extended permit tcp 1.1.1.1 ?
configure mode commands/options: A.B.C.D Netmask for source IP address asa5510(config)# access-list FromOutside extended permit tcp 1.1.1.1
You didn't say what model it was earlier, I thought it was an IOS router. IOS uses wildcard masks, which are the complement of netmasks.
Ok, so a day later, I finally figured it out... I was using Windows Explorer to test connectivity, but apparently, once the SMB connection is established on top IP, the ACL will no longer filter it until the connection is deleted within Windows or the firewall is rebooted. Is there another way to enforce the new ACL without these two methods? I tried to reapply the ACL to the interface using "access-group" but that didn't work.
You could try a clear xlate on the asa or pix. The issue is that the acl is applied when the connection is set up with the three way handshake. After that the ASA (Adaptive Security Algorithm) connection table will apply as long as the protocol rules are being followed. I think a clear xlate would clear this inromation and drop the connection without rebooting anything. From a windows perspective, you may have also been able to do a net use /d for each connection listed in a "net use" command until there are none to the dmz host. Then a subsequent connection would perform a new three way handshake.
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.