Extended ACL for DHCP

Hi,
I'm having a problem creating an ACL to allow DHCP.
I want to secure a VLAN running across our Cisco wireless network infrastructure to limit access as much as I can.
Restricting access to limited ip addresses and ports is straightforward, but I can't seem to get the ACL correct to allow clients to obtain ip addresses via DHCP.
I seem to remember that the ACL for DHCP was a little odd -this is what I currently have:
permit udp any host 172.16.30.4 log
permit tcp any host 172.16.30.4 log
permit tcp 172.16.36.0 0.0.0.255 host 172.16.30.4 eq domain established log
permit tcp 172.16.36.0 0.0.0.255 host 172.16.30.27 eq 8080 log
permit tcp 172.16.36.0 0.0.0.255 host 172.16.30.82 eq 443 log
deny ip any any (28 matches)
172.16.30.4 is the DHCP server, and I would like to limit this to only the ports required for DHCP, but I haven't specified whilst debugging this problem - my inital config was for ports 67 and 68.
I'm seeing traffic being logged against the deny ip any any, so I know the client is trying to send to the correct network etc.
The IP helper address is configured on the interface and is 172.16.30.4.
Can some one let me know what I'm missing.
Cheers,
Steve

Hi,
Thanks for the response - I'll try the ACL for DHCP shortly.
With regard to the ACL:
permit tcp 172.16.36.0 0.0.0.255 host 172.16.30.4 eq domain established log
you are correct, that is for DNS.
However, on reflection I believe I will need tcp and udp for this rule as the client device will update DNS dynamically when it obtains an IP address from DHCP and I seem to recall DNS updates require tcp port 53?
Cheers,
Steve

Similar Messages

WAAS: Standard vs Extended ACL's for WCCP Transparent Redirection

I've come across a number of implementations where the ACL's associated with services 61 & 62 are using extended access-list. I am writing with specific reference to wccp configured in promiscuous mode.
Since WCCP will only redirect TCP, and the WAAS solution in general applies only to TCP - then is there really a need for extended acls for redirection?. Furthermore, in a simple implementation you do not need separate acls linked to 61 & 62 - i don't think so.
Standard acls parse the filteration process more quickly than extended.
thanks
Ajaz

The extended access-lists are used because some TCP traffic does not to be optimized (telnet, BGP, SNMP, ...), or some hosts have compressed traffic for any application and need to be excluded from redirection. Besides that standard access-lists can be used.

Use extended ACL with NAT

Believe it or not, once in a while, i fumble with some basic concepts. Here is one, on our perimeter FW, ASA, there are these NATTING configured.
I just couldnt figure out why they use extended ACL for the sources? isnt the standard one good enough?
thanks in advance,
Han
access-list dmz_nat0_outbound extended permit ip any 1XX.169.0.0 255.255.0.0
access-list dmz_nat0_outbound extended permit ip any 10.48.240.0 255.255.255.0
access-list dmz_nat0_outbound extended permit ip any 10.48.243.0 255.255.255.0
access-list inside_nat0_outbound_5 extended permit ip any 172.17.13.0 255.255.255.0
access-list inside_nat0_outbound_5 extended permit ip any 192.168.12.0 255.255.255.0
access-list inside_nat0_outbound_5 extended permit ip any 192.168.221.0 255.255.255.0
global (Outside) 2 2XX.YY.13.244 netmask 255.255.255.0
global (Outside) 1 2XX.YY.13.12 netmask 255.255.255.255
nat (inside) 0 access-list inside_nat0_outbound_5
nat (inside) 1 0.0.0.0 0.0.0.0
nat (dmz) 0 access-list dmz_nat0_outbound
nat (dmz) 2 0.0.0.0 0.0.0.0

Hi Han,
If you go for the standard ACL then you cannot specify the destination subnets and ports. You can specify only the source and the destination is considered any by default.
standard ACL:
access-list 10 standard permit ip 172.16.0.0
Extended ACL:
access-list abc permit tcp 172.16.0.0 255.255.255.0 10.0.0.0 255.255.255.0 eq 80
This is how it differs. In your scenario destination is specific rather the source is any. So you have the extended ACL in picture for that. Hope this clears you.
Please do rate if the given information helps.
By
Karthik

IPv6 ACLs for ZBFW with changing IPv6 prefix?

Hi all
Is there a trick to keep IPv6 ACLs for ZBFW working when the IPv6 prefix will change ?
Background:
6RD based residential internet access.
Provider has a /28 6RD-Prefix, and will append the whole 32bits of the DHCP assigned public IPv4 address, leaving a /60 to use at home. Inside should be subnet 0, DMZ should be subnet 1 from that /60.
A few of my DMZ IPv6 hosts should be reachable from the outside world on specific udp/tcp ports, without having to open the whole DMZ subnet towards the IPv6 internet.
No big deal, one would think...
zone security Z-INTERNET
description * the outside world *
zone security Z-DMZ
zone security Z-OUTSIDE
zone-pair security ZP-OUTSIDE-TO-DMZ source Z-OUTSIDE destination Z-DMZ
service-policy type inspect PMAP-INBOUND-TRAFFIC
policy-map type inspect PMAP-INBOUND-TRAFFIC
class type inspect CMAP-IN-TRACE-TRAFFIC
pass
class type inspect CMAP-IN-INSPECT-TRAFFIC
inspect
class class-default
drop log
class-map type inspect match-any CMAP-IN-TRACE-TRAFFIC
match access-group name ACLv6-ICMP-UNREACH <-- some ICMP listed in this ACL, irrelevant here
class-map type inspect match-any CMAP-IN-INSPECT-TRAFFIC
match access-group name ACLv6-INBOUND-TRAFFIC
Now.. what would I put into ACLv6-INBOUND-TRAFFIC? Manually setting...
ipv6 access-list ACLv6-INBOUND-TRAFFIC
sequence 10 permit tcp any host <MYcurrent6RDPREFIX>1::<$MYHOSTID> eq http
... works well, until MY6currentRDPREFIX becomes MYnew6RDPREFIX. It does so seldomly, but it does, especially after outages.
For adressing (and re-adressing) the DMZ interface, "ipv6 general prefix MY6RDPREFIX 6rd tunnel6" helps a lot and it works pretty well.
However, one cannot seem to make use of "ipv6 general prefix" in an ipv6 ACL, neither as source nor destination (and neither when defining a stateful DHCPv6 server, for that matter).
router6rd(config-ipv6-acl)#permit ip any ?
X:X:X:X::X/<0-128> IPv6 destination prefix x:x::y/<z>
any Any destination prefix
host A single destination host
router6rd(config-ipv6-acl)#
D'oh. What now?
I do know that scanning the whole /64 would take aeons to complete, but I would like to use predetermined addresses with SLAAC and stateless DHCPv6 (with the help of http://man7.org/linux/man-pages/man8/ip-token.8.html).
Opening the entire subnet makes me cringe, even more since these hosts are bound to be in some public DNS as well. For that matter, it becomes largely irrelevant if the Host-ID comes from ip-token, EUI-64, RFC7217 or privacy extensions (allright, the latter wouldn't quite apply here, I know.)
Am I caught in the "IPv6 is like IPv4 but with longer addresses" trap? Should I just do away with my wish to have only the given DMZ servers reachable, and open up the entire subnet?
Or: Is there a completely different way of doing ZBFW things in IPv6 that I didn't think of?
thanks for your thoughts and ideas.
Marc

Hi all
Is there a trick to keep IPv6 ACLs for ZBFW working when the IPv6 prefix will change ?
Background:
6RD based residential internet access.
Provider has a /28 6RD-Prefix, and will append the whole 32bits of the DHCP assigned public IPv4 address, leaving a /60 to use at home. Inside should be subnet 0, DMZ should be subnet 1 from that /60.
A few of my DMZ IPv6 hosts should be reachable from the outside world on specific udp/tcp ports, without having to open the whole DMZ subnet towards the IPv6 internet.
No big deal, one would think...
zone security Z-INTERNET
description * the outside world *
zone security Z-DMZ
zone security Z-OUTSIDE
zone-pair security ZP-OUTSIDE-TO-DMZ source Z-OUTSIDE destination Z-DMZ
service-policy type inspect PMAP-INBOUND-TRAFFIC
policy-map type inspect PMAP-INBOUND-TRAFFIC
class type inspect CMAP-IN-TRACE-TRAFFIC
pass
class type inspect CMAP-IN-INSPECT-TRAFFIC
inspect
class class-default
drop log
class-map type inspect match-any CMAP-IN-TRACE-TRAFFIC
match access-group name ACLv6-ICMP-UNREACH <-- some ICMP listed in this ACL, irrelevant here
class-map type inspect match-any CMAP-IN-INSPECT-TRAFFIC
match access-group name ACLv6-INBOUND-TRAFFIC
Now.. what would I put into ACLv6-INBOUND-TRAFFIC? Manually setting...
ipv6 access-list ACLv6-INBOUND-TRAFFIC
sequence 10 permit tcp any host <MYcurrent6RDPREFIX>1::<$MYHOSTID> eq http
... works well, until MY6currentRDPREFIX becomes MYnew6RDPREFIX. It does so seldomly, but it does, especially after outages.
For adressing (and re-adressing) the DMZ interface, "ipv6 general prefix MY6RDPREFIX 6rd tunnel6" helps a lot and it works pretty well.
However, one cannot seem to make use of "ipv6 general prefix" in an ipv6 ACL, neither as source nor destination (and neither when defining a stateful DHCPv6 server, for that matter).
router6rd(config-ipv6-acl)#permit ip any ?
X:X:X:X::X/<0-128> IPv6 destination prefix x:x::y/<z>
any Any destination prefix
host A single destination host
router6rd(config-ipv6-acl)#
D'oh. What now?
I do know that scanning the whole /64 would take aeons to complete, but I would like to use predetermined addresses with SLAAC and stateless DHCPv6 (with the help of http://man7.org/linux/man-pages/man8/ip-token.8.html).
Opening the entire subnet makes me cringe, even more since these hosts are bound to be in some public DNS as well. For that matter, it becomes largely irrelevant if the Host-ID comes from ip-token, EUI-64, RFC7217 or privacy extensions (allright, the latter wouldn't quite apply here, I know.)
Am I caught in the "IPv6 is like IPv4 but with longer addresses" trap? Should I just do away with my wish to have only the given DMZ servers reachable, and open up the entire subnet?
Or: Is there a completely different way of doing ZBFW things in IPv6 that I didn't think of?
thanks for your thoughts and ideas.
Marc

Standard and Extended ACLs?

I just want to know that if extended IP access lists can do all tasks, I mean extended access lists have a lot of controlling parameters, then why people use Standard Access lists instead of Extended access lists.
I just want to know that in which scenario we should use STD ACLs instead of EXTD ACLs, what special advantage of using STD over EXTD ACLs,
Please reply.

Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
To summarize what the other posters have already noted, the two principle reasons why one might use a standard ACL (which could also be functionally accomplished) by an extended ACL are 1) some commands that rely on ACLs might still only support standard ACLs (more likely in older IOS versions) and 2) a standard ACL might be just a little clearer to understand.
Another (hopefully needless) reason why you might want to use a standard ACL, when an extended ACL would do, could be the device's processing performance might be better with a standard ACL.
Logically the standard ACL ACE:
access-list 10 permit host 1.1.1.1
should be the same as this extended ACL ACE:
permit ip host 1.1.1.1 any
But a "dumb" implementation of processing the extended ACL might wildcard compare the destination IP and other optional parameters while the standard ACL only examines the source IP. Should this happen? No, but such might happen because of different generations of code and/or different teams working on ACL processing.
BTW, if there is a significant performance difference, it's just as possible extended works better.
Again, this is very extreme and unlikely, but this could be a reason to use one form of ACL vs. the other when both can provide the same filtering. (Also, if this is "discovered", it's very likely to be very device and IOS version specific. Personally I would consider taking "advantage" of such a discovery poor practice, except in extreme situations.)

Best Practice for DHCP when Anchoring to a Guest Wireless LAN Controller

Hi all,
I'm interested in the communities opinion in relation to DHCP provisioning when using auto-anchor/guest tunneling.
As far as I can tell, one cannot use the internal DHCP on the anchor controller when using auto-anchor due to incompatibility between the auto-anchor feature and DHCP Option 82.
The scenario is as follows:
Guest controller is the anchor which provides Internet access to guests.
There is a foreign controller which is configured to anchor to the guest controller.
The internal DHCP server is configured on the guest anchor controller, therefore DHCP proxy must be enabled for DHCP to work.
DHCP proxy enables Option 82.
The guidlines for guest tunneling state that DHCP Option 82 isn't supported. (Ref: Deploying and Troubleshooting Cisco Wireless LAN Controllers - Ch14)
So, the internal DHCP server requires DHCP proxy to be enabled; this in turn enables Option 82, which stops DHCP leases being made to clients connected to the foreign controller.
Given that a guest WLC would normally be placed in a DMZ, the internal DHCP server may often be the only DHCP solution available.
I look forward to hearing your opinions.
Thanks
Rhodri Jenkins

There are a couple of options here if you need to get proxy disabled
1) pinhole with an ACL that allows dhcp to pass your internal servers
2) run dhcp on a switch, router, or firewall in the dmz
3) if you are using a cab,e modem or dsl for the guest users, you can let that do the dhcp
In general I've seen most of these in play, but I like option 2 myself
Sent from Cisco Technical Support iPad App

RDBMSRealm ACL for a URL

I have been unable to find or determine how to define a ACL for a URL using
the RDBMSRealm. We have implemented the example RDBMSRealm and I have found
the following about setting ACLs on URLs
Setting ACLs on URLs
weblogic.security.urlAclFile=urlAclPolicyFile
The weblogic.security.urlAclFile property specifies the name of a policy
file that extends the access control provided by the weblogic.allow
properties for WebLogic Server servlets that serve web pages and files,
including HTML pages, HTTP Servlets, and JSP pages. In the urlAcl policy
file, you can grant users and groups access to specific files and
directories. See Controlling access on URLs for specifics on setting up your
urlAcl policy file.
I want the ACLs for URLs to be read from the RDBMSRealm not from a
urlAclPolicyFile. Can I do it?
Thanks for any help.

there is no way to incorporate the ACL on URL into the RDBMSRealm. further, a
more forward-looking approach to this would be to use the URL access control
mechanisms in WebApplication DeploymentDescriptors. that way, it's J2EE
standard.
see also:
http://www.weblogic.com/docs51/classdocs/webappguide.html#dd_security
.paul
Jon Scoleri wrote:
I have been unable to find or determine how to define a ACL for a URL using
the RDBMSRealm. We have implemented the example RDBMSRealm and I have found
the following about setting ACLs on URLs
Setting ACLs on URLs
weblogic.security.urlAclFile=urlAclPolicyFile
The weblogic.security.urlAclFile property specifies the name of a policy
file that extends the access control provided by the weblogic.allow
properties for WebLogic Server servlets that serve web pages and files,
including HTML pages, HTTP Servlets, and JSP pages. In the urlAcl policy
file, you can grant users and groups access to specific files and
directories. See Controlling access on URLs for specifics on setting up your
urlAcl policy file.
I want the ACLs for URLs to be read from the RDBMSRealm not from a
urlAclPolicyFile. Can I do it?
Thanks for any help.

Help with some ACLs for VACL

I need some help with acls for a vacl. Goal - have the 1.1.1.0/24 subnet only communicate with certain IP.
So, they cannot get out to anywhere else and no one except that IP can get in.
Here is what I have so far:
access-list acl1 permit tcp 1.1.1.0 255.255.255.0 host 1.2.3.4
access-list acl1 permit tcp host 1.2.3.4 1.1.1.0 255.255.255.0
access-list acl1 ip 1.1.1.0 255.255.255.0 any log
access-list acl1 ip deny any any log
vlan access-map vacl1 1
match ip address set acl1
action forward
exit
vlan filter vacl1 vlan-list 11
Will this work as I expect it to?
Thanks for any help

Hi,
I implemented this on my 6509 and it didn't work. I even modified it to look like the following and it didn't work (I could RDP to one of the boxes on that the subnet).
ip access-list extended rapt_acl
deny ip any any
deny tcp any any
deny udp any any
vlan access-map rapt_vacl 10
match ip address set rapt_acl
action forward
vlan filter rapt_vacl vlan-list 90
Any thoughts what I may be missing?

Catalyst 3560 Extended ACLs

I have a VoIP / QoS situation I just discovered on the Cat 3560's. In this case, a particular manufacturer's IP Phones do not tag CoS or DSCP. As such, I have defined extended ACL's/Policies on the Cat 3560 switches to detect and mark traffic from the IP Phones. My policies are designed to identify and mark Call Bearer with DSCP 46 and Call Control traffic with DSCP 26 based upon source address and UDP port. What I see however, is that all VoIP traffic is marked at DSCP 46, and nothing is marked at 26. (It's not so bad having control and bearer marked with DSCP EF, but I like to put call control in a different queue when possible.)
I am looking for confirmaton of the following theory. I suspect that the 3560's ((C3560-IPBASEK9-M), Version 12.2(25)SED) are not layer 4 aware, thus extended access lists function only as standard access lists - (even though the switch allows me to create an extended ACL). As such, my attempt to identify call bearer and call signalling based upon UDP port will not work.
Below is the ACL / Policy config. Note that on downstream routers, I only see DSCP 46 and never match DSCP 26 (af31). From the switch, using "sh mls qos interface statistics", I see no traffic with DSCP 26 at all (output attached).
I believe this is because the switch is only reading the layer 3 portion of the ACL. Since both ACL 101 and ACL 102 have the same layer 3 source adress, then all classified traffic will match class "IngressVoiceBearer" and get marked with 46.
access-list 101 remark Voice Bearer Signalling
access-list 101 permit udp 192.168.100.0 0.0.0.255 any eq 5004
access-list 102 remark Call Control Signalling (udp 5440-5445)
access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5440
access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5441
access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5442
access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5443
access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5444
access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5445
class-map match-any IngressCallControlSignalling
match access-group 102
class-map match-any IngressVoiceBearer
description All Inbound Voice Bearer traffic on UDP 5004
match access-group 101
policy-map IngressVoIP
class IngressVoiceBearer
set dscp ef
class IngressCallControlSignalling
set dscp af31
class class-default
set dscp default
Switch Output:
switch#sh mls qos int g0/1 statistics
GigabitEthernet0/1
dscp: outgoing
0 - 4 : 12359302 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 1837749 0 9716 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0

Are the ports correct for the call control ACL? In the Cisco VoIP world we use an ACL like this for call control:
ip access-list extended VOICE-CONTROL
permit tcp any any range 2000 2002
permit tcp any range 2000 2002 any
permit tcp any any range 11000 11999
permit tcp any any range 1718 1720
permit udp any any range 1718 1719
permit udp any any range 2427 2428
permit tcp any any range 2443 2445
permit tcp any any range 5555 5599
But Cisco uses different protocols. Your ACL is configured correctly and the 3560 is supposed to support extended ACLs. Does your 3560 have an enhanced image or a standard image?
Are these Avaya phones? I have had to do software updates on Avaya phones to get them to behave correctly.
-Mark

Extended ACL permit ip and allowed ports

Hi everyone
Need to confirm if we have extended ACL with object group below
access-list xy_access_in extended permit ip object-group xy_subnets object-group cisco_ynetworks
will above ACL allow all the ports on the destination object group?
Thanks
mahesh

And to illustrate the situation above
Situation 1 - Only allow rule exists on the ACL
object-group network SOURCE
network-object 10.10.10.0 255.255.255.0
network-object 10.10.20.0 255.255.255.0
object-group network DESTINATION
network-object 10.10.100.0 255.255.255.0
network-object 10.10.200.0 255.255.255.0
access-list SOURCE-IN permit ip object-group SOURCE object-group DESTINATION
The above ACL would
Allow ALL TCP/UDP source and destination ports
Allow those from the source networks of SOURCE to the destination networks of DESTINATION
Situation 2 - Deny rules exist before the allowing rule
object-group network SOURCE
network-object 10.10.10.0 255.255.255.0
network-object 10.10.20.0 255.255.255.0
object-group network DESTINATION
network-object 10.10.100.0 255.255.255.0
network-object 10.10.200.0 255.255.255.0
access-list SOURCE-IN deny ip host 10.10.10.10 host 10.10.100.100
access-list SOURCE-IN deny tcp host 10.10.10.10 host 10.10.200.200 eq 80
access-list SOURCE-IN permit ip object-group SOURCE object-group DESTINATION
The above ACL would
First block ALL TCP/UDP traffic from host 10.10.10.10 to host 10.10.100.100
It would also block TCP traffic from host 10.10.10.10 to host 10.10.200.200 on the destination port TCP/80
It would then allow ALL TCP/UDP traffic from the source networks of SOURCE to the destination networks of DESTINATION
The key thing to notice ofcourse would be that we have blocked some traffic on the first 2 lines of the ACL and then allowed ALL TCP/UDP traffic.
So host 10.10.10.10 cant communicate with host 10.10.100.100 on any port since the "deny" rule for that is at the top of the ACL BEFORE the rule that allows ALL TCP/UDP traffic between these networks.
In the other case the TCP/80 destination traffic from host 10.10.10.10 to host 10.10.200.200 would be blocked BUT rest of the TCP/UDP traffic would be allowed by the rule using the "object-group"
- Jouni

Extended ACL Issue

I have a question, I am trying to make an extended ACL to deny HTTP, Telnet, and FTP traffic from the internet to PC1 in the one exercise I am doing.
I made the following ACL and applied it to the loopback interface on R2 (where the ISP is coming in from the "cloud") PC1 is connected to R1 which is obviously connected to R2.
ip-access-list extended ACL_TCP
deny tcp 209.165.200.160 0.0.0.31 10.0.0.0 0.0.0.127 established
permit tcp any any established
Is there a better way to do this? Does this extended ACL work for my purpose?

What direction did you apply this? I'm assuming in the inbound direction?
Take the established keyword off. That's generally to allow return traffic on an interface that's denying traffic.
Try the following:
ip access-list ext ACL_TCP
deny tcp 209.165.200.160 0.0.0.31 10.0.0.0 0.0.0.127 eq http
deny tcp 209.165.200.160 0.0.0.31 10.0.0.0 0.0.0.127 eq ftp
deny tcp 209.165.200.160 0.0.0.31 10.0.0.0 0.0.0.127 eq telnet
Apply to your loopback:
ip access-group ACL_TCP in
Next question:
Why do you have an acl applied to your loopback and not the physical interface that your internet connection comes in on? Normally, you would apply to say s0/0 (serial interface) that has your public ip assigned to it. That may be why it's not working. You actually have the acl applied to LoopbackX?
HTH,
John

ACLs for Nexus7k & 6500 switch

Can we use same ACL for both Nexus7k & 6500 switch? or not
ip access-list <name>
ip access-list extended <name>

- On the Cat6500 switches you will be able to use the same syntax that you have been using in the past and have listed in your question
- The NX-OS would be very similar with some cool additional features. Also, you no longer have to worry about specifying if the ACL is standard or extended. Check out the links below for more info and examples:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/security/configuration/guide/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_6-x/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_6-x_chapter_01110.html#con_1458580
http://www.ccierants.com/2013/07/ccie-dc-acls-on-nexus-7k-5k-and-1k.html
I hope this helps!
Thank you for rating helpful posts!

Applying Extended ACL close to Destination

Hi Everyone,
Need to share something here.Mostly we use extended ACL close to the source.
Here is this scenario i need to use the extended ACL close to destination to fix the issue.
Here is info
Server 1 connected to interface X ASA1 it has wan connection to ASA2---ASA2 has connection to ASA3.
Now ASA3 is learning source server IP via its Y interface.
In order to reach the destination server ASA3 has to through its interface Z.
Now there was ACL on ASA3 which denies traffic from source server IP to destination IP on interface Y.
I apply the ACL on ASA3 to allow the traffic and it worked.
Dooes someone elase also has seen this behaviour?
Regards
Mahesh

Hi,
The thing depends on the fact if I understood your setup correctly. If you have traffic flowing through 3 different firewalls to reach its final destination then naturally you have to make sure that each of those firewalls allow that traffic. Even if the first ASA1 allows this connections in its ACL rules it might still be that ASA2 or ASA3 has a configuration that doesnt allow this traffic (like it seemed to be originally in your situation). The fact that ASA1 allowed the connection attempt through itself doesnt mean that it would reach its destination as there are differen firewalls on the way.
Just as an example I could mention one real life setup that I manage.
The setup contains 4 firewalls always (at minimum)
One is customer firewall/vpn device
One is our vpn device
One is our firewall device
One is our partner firewall device
This means essentially that for the Customer to reach the Partner sites servers the traffic has to go through 4 firewalls atleast. Because of the policy chosen we only have to make sure that the Customer and the Partner firewall allows the traffic as Our firewalls dont do any access control (just provide the connectivity between sites)
- Jouni

Extended Notifications for SAP Business Workflow

Hi expert,
i need your help!!
i have configured the "Extended Notifications for SAP Business Workflow" with the tnx SWNADMIN and this was successful. I can write emails, but i can read this only on SAP GUI with the tnx SOST. I don't receive email on my email-address.
can you say me, where is the problem?
Thank you in advance
marcel

Hi Marcel
Rope in your Basis Guy!
Basically, your Extended notif part is working fine..... emails reaching SOST is proof. Going out of SAP may need basis config.
What do you see, a yellow triangle or a red light in SOST?
Regards,
Modak

My Samsung Network Extender worked for years, but no longer works. How do I fix it?!

My Samsung Network Extender worked for years. I switched away from Verizon only to find out it won't work when my phone is on another network. I have since switched back to Verizon and now my Network Extender does not work AT ALL. I will switch away again if this problem is not resolved.

We would be delighted to assist elsdpe! Have you contacted us to readd the Network Extender to your account? If not please contact us directly at 800-922-0204. We look forward to hearing from you soon, thanks!
MatthewS_VZW
Follow us on Twitter @VZWSUPPORT

Extended ACL for DHCP

Similar Messages

Maybe you are looking for