Missing Policy rule precedence for classification type "IP socket"

[aloeffle]

Dear all.

I need to reorder the default policy rule precedence in our setup.
Our goal is, that rules match "ip destination socket" are handeled before "ip destination" then "tcp port destination" rules.

udpdestportIP 53:10.0.0.10 mask 48 forward
ipdestsocket 10.0.0.0 mask 24 drop

Checking the default rule precedence, there is no parameter for "ip destination socket".

SSA Chassis(su)->show policy profile 5
...
Rule Precedence :1-2,29,3-19,23,20-22,25-28,31
:MACSource (1), MACDest (2), Application (29),
:IPXSource (3), IPXDest (4), IPXSrcSocket (5),
:IPXDstSocket (6), IPXClass (7), IPXType (8),
:IPv6Source (9), IPv6Dest (10), IPv6Flow (11),
:IPSource (12), IPDest (13), IPFrag (14),
:UDPSrcPort (15), UDPDestPort (16), TCPSrcPort (17),
:TCPDestPort (18), ICMPType (19), ICMP6Type (23),
:TTL (20), IPTOS (21), IPProto (22), Ether (25),
:LLCDSAPSSAP (26), VLANTag (27), TCI (28), Port (31)
Admin Profile Usage :ge.1.20
Oper Profile Usage :ge.1.20
Dynamic Profile Usage :none

Does anyone have an idea how to handle this?

EOS: 08.62.01.0034
EMC: 7.1.1.9

Thanks and best regards
Alex

[aloeffle]

Hello Tyler.

Thanks for your detailed explanation. I am familiar with emc.

I did some tests in my lab and I can confirm what you said. IP Socket Destination has precedence over IP destination. It is not necessary (and obviously not possible) to change the rule precedence.

Thanks for your help!

Best regards

Alexander

[bnfcorbett]

Hello Tyler,

I am facing a similar problem to aloeffle and was hoping you could explain to me what you mean by the following sentence:

“The main difference is that you would specify the servers that are running DHCP and DNS by either a dedicated IP address or by using an Automated service.”

I have tried to put in a IP Socket Destination rule for our internal DNS but it is trumped by the IP Address Destination rule to deny access to the internal server LAN (where our DNS server resides).

Were you referring to an IP Socket destination or something else?

Thanks

Brian

[TylerMarcotte]

Alexander,

This is actually a quite common deployment. I'm not sure of the exact CLI syntax on the switch, but since you have Management Center anyway, I would always recommend configuring policy from there.

From Management Center, you would create a policy that is very similar to what you have. The main difference is that you would specify the servers that are running DHCP and DNS by either a dedicated IP address or by using an Automated service. The example I have below shows a single server that's running DHCP and DNS in the private network. That takes precedence over dropping the IP range of a the private network. So in essence the priority would be:

Allow DHCP to 10.0.40.100 (assumed server)
Allow DNS to 10.0.40.100
Deny IP to 10.0.40.0/24
Allow ARP
Allow HTTP
Allow HTTPS

Let me know if that helps. I can provide more screenshots if you'd like or I can export the PMD file as well.

Thanks,

Tyler

[aloeffle]

Dear Tyler, Patrick.

thanks for your help.
I notice, that I should find a different solution then changing the rule precedence.

My requirement is quiet basic.

Client Network "332" : 10.0.254.0/24
Clients should have Internet Access http & https
DNS & DHCP to internal network
No other communication

Internal Network: 10.0.40.0/24
Here we have the DHCP & DNS Server which serves Client Network 332.
And there are several other Server with http/https Web Management.

A Policy which

dns forward
arp forward
dhcp forward
http forward
ip drop

=> Clients can establish unwanted connections to the Web GUI of 3rd party Server in 10.0.40.0/24.

A Policy which

dns forward
arp forward
dhcp forward
http forward
10.0.40.0/24 drop

=> No more DNS/DHCP

Plan B:
With the recommendation not to change the precedence, I plan to apply an ACL which deny http traffic to the internal network.
(or changing the dns/dhcp design)

Best regards
Alexander