06-11-2010 03:51 AM - edited 03-04-2019 08:45 AM
Help,
In preparation for a new ISP connection I have setup a router to ensure connectivity to our new ISP. The routers are working the BGP session established and the default route delivered from the ISP.
Now, what I'm trying to do is take the router behind a CheckPoint (R70.3 on SPLAT) and establish the BGP session. I am using Network Adress Translation on the firewall to tanslate the internal router address to the expected neighbor address the ISP is expecting.
I can ping from the internal router to the External gateway and the BGP Neighbor. However the BGP session will not establish. I see a BGP request go out and also request come in from the ISP's router but it does not establish.
When it was working ie testing from a router externally I hade the ebgp-multihop to 2 I am assuming this would stay the same internally.
Any pointers would be greatly appreciated.
P.
06-11-2010 04:47 AM
BGP uses TCP to create/establish neighbors - allow TCP 179 thru the firewall and increase your multihop to 3
HTH>
06-11-2010 05:56 AM
The BGP rule is there for TCP connectivity on Port 179. The internal router is only reaching the OpenConfirm state which would suggest traffic has been passed in both directions?
So close I know it.
P.
06-11-2010 06:25 AM
Sounds to me like the internal router is waiting for a reply - what does the log show in the CP firewall? Can you see the reply from the external BGP speaker? Check the NAT address is correct?
06-11-2010 08:57 AM
To get a BGP session to work through an ASA we must disable ‘TCP random sequence numbers’; perhaps something similar is happening with the checkpoint.
If you are using an MD5 has with your BGP session that also has to be accounted for in the ASA by allowing a specific TCP option; not sure if the checkpoint is also intrusive in that regard.
Chris
06-14-2010 02:43 AM
Hi,
that sounds about right, I am getting:
%TCP-6-BADAUTH: Invalid MD5 digest from x.x.x.x(15555) to x.x.x.x(179)
Passwords are correct as this has been checked by testing with the firewall out of the equation.
Will see what checkpoint have to offer on this problem.
P.
06-29-2010 09:14 AM
Problem resolved by not using NAT. appears that the IP address
Source & destination are used somewhere in the MD5 computation. All working now but had to find out the hardwat just lucky that our ISP is very accomodating.
P.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: