Routing

Hey everyone 🙂

I wanted to try something different but it doesn't seem to be working. Maybe i can't do this maybe i can. I created a rule to basically hijack all NTP requests and i wanted to use the next-ip directive to forward it to my local NTP server.

This is the rule(s) I created.

set firewall family inet filter FLTR-IN term 5-T-NTP-HIJACK-EXECEPT from source-address 10.0.0.2/32
set firewall family inet filter FLTR-IN term 5-T-NTP-HIJACK-EXECEPT from port 123
set firewall family inet filter FLTR-IN term 5-T-NTP-HIJACK-EXECEPT then accept
set firewall family inet filter FLTR-IN term 5-T-NTP-HIJACK from source-address 0.0.0.0/0
set firewall family inet filter FLTR-IN term 5-T-NTP-HIJACK from destination-port 123
set firewall family inet filter FLTR-IN term 5-T-NTP-HIJACK then next-ip 10.0.0.2/32
set firewall family inet filter FLTR-IN term END then accept

The first part so the actual NTP server can reach other servers and the 2nd part to hijack any server trying to hit dest port 123.

In theory, I should be able to do "ntpdate -qu 8.8.8.8" behind that router and it should hit my NTP box instead correct? I have this rule on the input side of my links which is where i have smtp block rules that work well. I figured this was the same fashion just a different port and im not using "from prefix-list" I'm using from Anything using 0.0.0.0/0

Am i incorrect on understanding what this next-ip function does?

Thanks for all the help!

Hi xfxchilde33,

So far what I am understanding is that traffic from 10.0.0.2 from port 123 should continue normally. Then traffic from 0/0 to a destination port must be sent to 10.0.0.2.

If I am correct first we need to see if the filter is applied correctly to the packets, I suggest to add a counter set firewall family inet filter FLTR-IN term 5-T-NTP-HIJACK then count NTP-HIJACK

Then if counter increase it means that the packets are been filter, then check if the packets are going out through the outgoing interface with another counter as output

from

  source-address 0.0.0.0/0

  destination-port 123

then

  count NTP-HIJACK-OUT

term 2 END

 then accept

After those steps we can determine where the filter is not working correctly.

Kudos is always appreciated!

Hello,

The 10.0.0.2 must be on directly connected interface, MX does ARP for this IP.

If it is not, the ARP fails and hence the rule isn't working.

HTH

Thx

Alex

Hey xfxchilde33,

Next-ip is used when you have a policy-based forwarding or as it is named in the Junos real filter-based forwarding. Filter based forwarding will help you to accomplish what you are trying to do by sending the desired traffic to another routing instance to be treated differently,  here is how you can configure an FBF: https://www.juniper.net/documentation/en_US/junos/topics/example/filter-based-forwarding-example.html

Now to answer your question of this knob and a possible use case, please see the example below:

Suppose, for example, that you want to offer services to your customers, and the services reside on different servers. An example of a service might be hosted DNS or hosted FTP. As customer traffic arrives at the Juniper Networks routing device, you can use filter-based forwarding to send traffic to the servers by applying a match condition on a MAC address or an IP address or simply an incoming interface and send the packets to a certain outgoing interface that is associated with the appropriate server. Some of your destinations might be IPv4 or IPv6 addresses, in which case the next-ip or next-ip6 action is useful

source: https://www.juniper.net/documentation/en_US/junos/topics/topic-map/filter-based-forwarding-policy-based-routing.html#jd0e784

If this solves your problem, please mark this post as "Accepted Solution" so we can help others too \:)/

Regards,

Lil Dexx
JNCIE-ENT#863, 3X JNCIP-[SP-ENT-DC], 4X JNCIA [cloud-DevOps-Junos-Design], Champions Ingenius, SSYB

Thank you for all the replies. 10.0.0.2 was a placeholder IP. Its actually a public IP i input there. It is not directly attached to the MX480 but it is inside the network for it. I'm trying to redirect all NTP traffic to an internal NTP server no matter what IP someone were to try to use inside of my network i'd want it to hit my NTP server.

I have my MX480 which is connected to my NSPs and it is also connected to my aggregation switches (QFX5100s) So i was using the input method on the interface on the mx480 side to try to redirect such traffic. The QFX5100 does not have the next-ip function, so i would not be able to write the rule where the CIDR lives on an IRB.

Is there another way for me to "Redirect NTP Traffic to X server"

Thanks!

Have you considered using the filter based forwarding option ? as mentioned before this would definitely accomplish your goal

xfxchilde33

Greetings, Have you considered using the filter-based forwarding option? with this feature you can send all of the NTP traffic to a forwarding routing-instance with a firewall filter( similar to what you were trying to do, instead of then "next-ip" it will be then "routing-instance + name" ) then, in the forwarding routing-instance you create a default route pointing to your server.  

Please check this link for mode information and a config example: https://www.juniper.net/documentation/en_US/junos/topics/example/firewall-filter-option-filter-based-forwarding-example.html

If this solves your problem, please mark this post as "Accepted Solution" so we can help others too \:)/

Regards,

Lil Dexx
JNCIE-ENT#863, 3X JNCIP-[SP-ENT-DC], 4X JNCIA [cloud-DevOps-Junos-Design], Champions Ingenius, SSYB

Hello,

---

@xfxchilde33 wrote:

10.0.0.2 was a placeholder IP. Its actually a public IP i input there. It is not directly attached to the MX480 but it is inside the network for it.

"next-ip" is not supported for NON-directly attached IP addresses.

---

@xfxchilde33 wrote:

 

Is there another way for me to "Redirect NTP Traffic to X server"

 

 

---

Short answer - there is no "one and done" command or feature on MX that fits Your goal.

Long answer - if You still insist on using a NON-directly attached IP as redirection target, then every node in the path has to agree/has to be configured similarly to redirect Your NTP traffic to that IP. 

Or You have to use some kind of tunnel starting on MX and terminating on that redirection target, or penultimate hop to redirection target, in order to let intermediate nodes to do the routing based on outer header (be it GRE, IPIP, IPSec or MPLS). BTW, that's what Traffic Engineering is for - to provide non-shortest paths through the network for certain categories of traffic.

HTH

Thx

Alex 

Thank you for your input. I figured that was going to be the case. I have vlan-tagging on the QFX links. I'll create a new unit and make the server on the QFX side use the new unit on the uplink from the MX480 so its directly attached.

Thanks!

So I'm making progress but no dice yet!

I moved the IPs to a unit on the QFX link MX side.

run show arp no-resolve | match 123.123.123.123
46:ff:be:f7:ef:1c 123.123.123.123 ae1.647 none

I'm getting an ARP entry now. 

I'm seeing the counter rise as well

Counters:
Name Bytes Packets
NTP-HIJACK 1648931 21703

However if i try to do something like ntpdate -qu 8.8.8.8 I still get a no server message so its still not forwarding to the IP but its being filtered? Whats the next step.

I'm using 8.8.8.8 as a "random ip that i know does not have NTP setup"

Actually i just did a commit confirm on the following 

set firewall family inet filter FLTR-IN term 5-T-NTP-HIJACK from destination-address 8.8.8.8/32
set firewall family inet filter FLTR-IN term 5-T-NTP-HIJACK from destination-port 123
set firewall family inet filter FLTR-IN term 5-T-NTP-HIJACK then count NTP-HIJACK
set firewall family inet filter FLTR-IN term 5-T-NTP-HIJACK then next-ip 123.123.123.123/32

I'm still returning the following:

[root@localhost~]# ntpdate -qu 8.8.8.8
server 8.8.8.8, stratum 0, offset 0.000000, delay 0.00000
24 Jul 08:07:22 ntpdate[96741]: no server suitable for synchronization found

So i'm convinced its just not working at all even when i specify destination address and port.

Currently it seems all this filter is doing is rejecting any ntp traffic and not really changing the destination address at all. 

For anyone trying to accomplish this lol....

So i did a tcpdump on the NTP server and it saw the request as the ip entered by the client not the IP used for next-ip in the firewall rule.

On the NTP server i used some iptables and BINGO!

[root@localhost ~]# ntpdate -qu 123.123.123.123
server 123.123.123.123, stratum 3, offset -0.035794, delay 0.02586
24 Jul 08:22:14 ntpdate[425005]: adjust time server 91.132.1.134 offset -0.035794 sec
[root@localhost ~]# ntpdate -qu 8.8.8.8
server 8.8.8.8, stratum 3, offset -0.035754, delay 0.02589
24 Jul 08:22:23 ntpdate[427071]: adjust time server 8.8.8.8 offset -0.035754 sec
[root@localhost ~]# ntpdate -qu 1.1.1.1
server 1.1.1.1, stratum 3, offset -0.035764, delay 0.02583
24 Jul 08:22:54 ntpdate[434411]: adjust time server 1.1.1.1 offset -0.035764 sec

Iptable rules used:

iptables -t nat -A PREROUTING -p udp --dport 123 -j DNAT --to-destination 123.123.123.123:123
iptables -t nat -A POSTROUTING -j MASQUERADE

Thanks for everyones help!!! I hope this helps someone else in the future!!

Hello,

---

@xfxchilde33 wrote:

 

So i did a tcpdump on the NTP server and it saw the request as the ip entered by the client not the IP used for next-ip in the firewall rule.

 

---

This is expected. Let me tell You what MX "next-ip" feature does NOT do:

1/ it does not do src NAT on the original packet 

2/ it does not do dst NAT on the original packet

3/ it does NOT do any other IP address substitution in the header or body of original packet

4/ it does NOT do HTTP 3xx redirect

5/ it does not do any kind of tunneling original packet towards that "next-ip".

And now what the MX "next-ip" feature DOES:

1/ it tries to send ARP request for IP entered as "next-ip". If this IP is NOT on directly connected MX interface, this ARP request fails. Fullstop.

2/ if the IP entered as "next-ip" resides on directly connected MX interface, and ARP resolves, then

3/ the original packet is encapsulated with dst MAC == MAC of "next-ip" taken from ARP above, src MAC == MX interface MAC, and sent out that connected interface.

Hope this makes sense.

HTH

Thx

Alex

Alex,

100% understand now that i went through this process. This is very useful. I just have to make sure the IP is on the MX to use it for other things 🙂

Thank you everyone!