03-24-2024 08:47 AM
Hello, I would like to implement an ACL that would only allow returning traffic to the WEBTERM server ( initialised by the WEBTERM, no other traffic).
The commands I used were :
ip access-list extended REFLEXIVE
permit tcp any 172.16.30.0 0.0.0.255 established
Applied on the R5 MLS Fa0/1 outbound ( to run the returning traffic/other-network-initialised traffic through the ACL? )
What would be a way to test it?
If I'm right, trying to get a DHCP configuration on the WEBTERM wouldn't work since it's UDP traffic? Took down the access-group from the interface, got a DHCP config, it worked. Put the access-group back on the interface, went static on the WEBTERM, back on auto, also got the DHCP config.
Why does it work like this?
The only proof I have would be that the PC's can no longer access the HTTP service (from the WEBTERM) through the DNS server I guess?
What would be a case that would match the permit tcp any 172.16.30.0 0.0.0.255 established acl functionality in this case?
Solved! Go to Solution.
03-24-2024 03:40 PM
Was your intent to actually use a reflexive ACL?
If so, your OP ACL isn't how you structure one.
The establish TCP option and reflexive ACL are not the same.
A reflexive ACL can handle some UDP, but a established ACL is TCP only.
Have you seen "Configuring IP Session Filtering (Reflexive Access Lists)"?
If you do want to use the established option, more information for using it can be found in: "Configure Commonly Used IP ACLs"
03-24-2024 09:32 AM
Since you have ACL TCP - So DHCP not going work, if you like to allow all use IP instead of TCP so it cover all TCP and UDP
DHCP :
► UDP port 67 (That's a DHCP server)
► UDP port 68 (That's a DHCP client)
03-24-2024 03:40 PM
Was your intent to actually use a reflexive ACL?
If so, your OP ACL isn't how you structure one.
The establish TCP option and reflexive ACL are not the same.
A reflexive ACL can handle some UDP, but a established ACL is TCP only.
Have you seen "Configuring IP Session Filtering (Reflexive Access Lists)"?
If you do want to use the established option, more information for using it can be found in: "Configure Commonly Used IP ACLs"
03-25-2024 03:24 AM
Yes, I was mistaken. I thought a reflexive ACL was just another term for an ACL with the "established" keyword since I saw on another post a similar problem with the reflexive tag. I will try and get familiar with the reflexive ACL since it sounds like it could be the solution to my problem. Thank you !
03-25-2024 06:58 AM
BTW, another option to consider would be using NAT.
03-27-2024 08:32 AM
Sorry for the late answer, how would you go about doing that? I'm fairly new to NAT and the only function I can think of is the translation from a private address to a public one.
03-27-2024 02:58 PM
@vladionescu26 wrote:
Sorry for the late answer, how would you go about doing that? I'm fairly new to NAT and the only function I can think of is the translation from a private address to a public one.
Pretty much as you would for private (internal/hidden) address to a public (external/known) address.
The key would be to use PAT, which usually generates dynamic/temporary stateful internal/external translations. I.e. an external host would need to be replying to a packet initially sent by the internal host.
Dynamic NAT also generates dynamic/temporary stateful internal/external translations, but once opened they are open to any port.
I only mentioned NAT(PAT) because it too has the feature of generating stateful translations. For your purpose, the ACL is likely a better choice.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide