Thumbnail: logo

BGP peering behind NAT overloaded (PAT) network

by on under blog

It may happen that you are trying to establish a BGP neighborship between two devices, let’s call them A and B. Suddenly after session establishment, A send a notification message and tear down the the connection versus B. Then you discover that BGP speaker A,  has never got any keepalive from B, except the initial two successful ones. Speaker A hence, as RFC states, it properly disconnect the session after hold down timer has expired.

So you check speaker BGP messages, and notice that it has correctly sent all the later keepalives. At this point you learn that NAT overload is enabled between A and B,  so that A resides on an inside network. But what if A will be forced to actively initiate the connection with the command:

neighbor [ip address]  transport connection-mode active

This should solve all our problems since all the connections are initiated from inside to outside, isn’ it? Well, it depends:if you have wide BGP keepalive timers your NAT table may have already cleared the session and drop any incoming packet that has no match in the dynamic translation table. Which is, on some firewalls/IPS, common behaviour.



© 2018 Matteo Malvica. Illustrations by Sergio Kalisiak.