Allow returning traffic with ACL established

[vladionescu26]

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?

[balaji.bandi]

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)

[Joseph W. Doherty · Accepted solution]

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"

[vladionescu26]

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 !

[Joseph W. Doherty]

BTW, another option to consider would be using NAT.

[vladionescu26]

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.

[Joseph W. Doherty]

---

@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.