Log in to ask questions, share your expertise, or stay connected to content you value. Don’t have a login? Learn how to become a member.
Good question @Jason . Just like any other traffic traversing that NAT device, SVR sessions are discrete (i.e. each one has a unique 5-tuple, or SRC-IP, SRC-Port, DST-IP, DST-Port, and transport protocol) and they are directional (i.e. it initiates from one place to another to begin a bi-directional flow). So a NAT device that is keeping track of flows or connections is going to see the same number of them with or without those sessions being SVR'ed.
By default, two peered routers are going to send TCP/UDP packets between their adjacent waypoint (L3 interface) addresses using the following ports:
1280 (Bidirectional Forwarding Detection)
16348 - 65535 (sessions)
So a NAT is going to need to allow traffic on these ports be default.
Note that it is also going to need to allow connection or flow establishment from one side of it to another in the direction of the service for things to work. For example, most NATs allow a connection to go from ""inside"" to ""outside"", but not the other way around. Again, no different from any other traffic, if you have a service on the ""inside"" of the NAT you'll need to make sure it forwards traffic from ""outside"" (can be limited to just that coming from the peered waypoint address). If the entire range of ports listed above can't be opened between the waypoints, you can configure sessions to be sent to a specific port, or range of ports. You do this using the ""Port Range"" setting on a specific adjacency.
When you set a port range, you'll select from the following set of ports:
1025 - 16383
Thanks @Reid for the detailed response. Exactly what I was looking for...
@Reid When devining the Port Range, you say ""on a specific adjacency"". If I'm using neigborhoods, would I define the Port Range within the Neighborhood settings under the Network Interface of the router that is sitting inside the firewall? Are there any guidelines on how to decide how big of a port range to use?
@Austin That's correct, you could define your custom port range in the neighborhood, on the router that sits behind the firewall. This will impact the adjacency(ies) created for this router on the peer router(s). In terms of the total number of SVR sessions that can be supported between any given pair of peers, it's roughly the product of the two peers' waypoint port ranges. So, if one router has 16K ports, and the other has 8, the total number of concurrent sessions will be approximately 128K.
@Austin you are correct. If my router `r1` was behind a FW that was forwarding specific ports through to `r1`'s waypoint address, then on that `r1` network-interface neighborhood you would specify the ports. With that, you should see all remote peers in the neighborhood reflect the port in their adjacency to `r1`, and when they send sessions to `r1`, they will target the specified ports.
The main consideration if you are required to operate under a specified set of ports, is that by limiting the ports which can be used for sessions, you are limiting the number of sessions that can be active from any one peer to that waypoint. So the bigger the better IMHO ? .
Would you still need to set that port range scope, if you have Peer Connectivity set to outbound only on r1?
@Austin, to me the port range is significant when you also port forward your NAT on this very port range. If you are not employing port forwarding, then you should use ""outbound-only"" setting, and as long as the NAT allows the traffic to flow from inside to outside freely, you can leave the port range at its default settings.
Now, in the unfortunate event when you have a NAT in front of each of the two 128T peers, one of them must be port forwarded on port 1280, as well as ports that are in the session pool, for example 8001-16000.
@Austinto add to @Gene's comments, by setting ""outbound-only"" on a given interface's neighborhood, you are declaring that the waypoint has outbound only reachability, and that a peer in the neighborhood would not be able to send a new inbound session to it's waypoint due to restrictions of a NAT or Firewall. This causes the peers to use NAT/FW traversal techniques to get around the connectivity restrictions. The end result is that sessions work bidirectionally in spite of the presence of a NAT of FW in the path.
In your case, if you set up a port-forward of one or more ports, you are actually arranging bidirectional connectivity through the NAT/FW. So a peer can in fact send an inbound session (on the ports you've arranged and configured).
Thanks @Gene and @Reid for the quick answers.