You are on page 1of 1

allow traceroute in SRX or not

If you have a restricted policy that you have enforced for your internal clients but you want to
allow traceroute requests from your internal clients towards another network you can do it as
follows I suppose. You can create the following application and apply it on your security policy.
[edit applications]
root@srx100-1#
application custom-traceroute {
protocol udp;

1
2
3
4
5
6

[edit applications]
root@srx100-1#
application custom-traceroute {
protocol udp;
destination-port 33434-33534;
}
I took port range from wikipedia for traceroute. When you test from a linux client (I think
windows is using icmp instead), you will see UDP requests destination port of which start from
33434. So far good. Once you set this application inside the policy, clients are allowed to use
traceroute from their linux clients but should we really allow this? I think no. Look what happens
in the session flow if you allow this traceroute:
root@srx100-1> show security
Valid sessions: 27
Pending sessions: 0
Invalidated sessions: 0

1
2
3
4
5
6

root@srx100-1> show security flow session protocol udp summary


Valid sessions: 27
Pending sessions: 0
Invalidated sessions: 0
Sessions in other states: 0
Total sessions: 27
In my linux client, I saw 13 hops after my traceroute which itself created 27 flow sessions in my
SRX as it is UDP, session timeout is 60 seconds but anyway. It is better not to allow traceroute
even from internal clients! or you can reduce the inactivity-timeout of this custom traceroute
application.

You might also like