Firewall rules for LDP (MPLS)

Hi guys,
According to RFC 5036 section 3.10.1, LDP uses TCP and UDP port 646 for its communication.

I have created 4 firewall rules for this:

action=accept chain=input dst-port=646 protocol=tcp
action=accept chain=input dst-port=646 protocol=udp
action=accept chain=output dst-port=646 protocol=tcp
action=accept chain=output dst-port=646 protocol=udp

LDP seems to be working perfectly, but the counter for the firewall rule allowing TCP 646 output, does not count any hits.

Do any of you smart people know why? Is this firewall rule for some reason not needed?

Best regards,
Marius

Try to select the output and input interfaces in rules.

Hi Anumrak,

I don’t quite follow… Du you suggest that i narrow down my firewall rules by selecting an interface? I have other routers conneted to all interfaces of this device, and will want LDP to work for all of them.

I have the allow TCP 646 output firewall rule on top of my list, and the counter is still on zero. It looks like there is really nothing leaving my router destined to port TCP 646 anywhere. The input rule for TCP 646 counts vigorously. LDP works like a charm…

  • Marius

I don’t have specific LDP knowledge, but it is normal that when you have TCP rules with a dest-port they only match in one direction.
The other direction is typically matched by an “established” rule further up the chain.
Remember TCP connections are normally made with a random source port number to a fixed destination port number, and so the
replies in the other direction are from a fixed source port number (the service port) to a random destination port number.

Just checked. LDP, unlike ISAKMP f.e., using random source port and 646 as destination. That’s why you can’t see the counters in rules. Also you can use “torch” for traffic sniffing and see TCP ports.

That… is probably it. Of course…
It will select some random high port as source port, and match it as established. I understand now.

Thanks, pe1chl and Anumrak!

  • Marius

The use of a fixed source AND destination port is typically seen only with UDP, not with TCP.
When you would want to restrict the output (output chain is usually left empty…) you would have to match on the source port at the service side.