BGP using wrong source IP

[araatn]

Hi,

I have setup a s2s routed based vpn with BGP on it and this s2s vpn is established.

I can ping the other side which is 192.168.1.1 and my side is 172.23.0.1. But I have this  strange situation which might lead to a bug (I think):

Firmware of the FTG = v6.0.6 build0272

My FTG should use the source IP 172.23.0.1, but its using port 1 which is my public IP (83.140.160.1) to negotiate BGP towards 192.168.1.1.  I've also configured update source & source on BGP to use port2 which is 172.23.0.1

I don't find any bugs on the v6.0.6 about this, but does anyone has this experience??

Also there is no nat active ;) 

FW_A_001 (bgp) # show config router bgp     set as 6000     set router-id 172.23.0.1     config neighbor         edit "192.168.1.1"             set ebgp-enforce-multihop enable             set interface "port2"             set remote-as 65011             set route-map-in "rm-AZURE-IN"             set route-map-out "rm-AZURE-OUT"             set update-source "port2"         next     end     FW_A_001 # show system interface port2 config system interface     edit "port2"         set vdom "root"         set ip 172.23.0.1 255.255.252.0         set allowaccess ping https ssh snmp http fgfm capwap         set type physical         set alias "LAN"         set device-identification enable         set device-identification-active-scan enable         set snmp-index 6     next end     flow of bgp: FW_A_001 # id=20085 trace_id=125 func=print_pkt_detail line=5494 msg="vd-root:0 received a packet(proto=6, 83.140.160.1:16105->192.168.1.1:179) from local. flag , seq 2878734237, ack 0, win 13980" id=20085 trace_id=125 func=init_ip_session_common line=5654 msg="allocate a new session-0afcfab0" id=20085 trace_id=125 func=ipsecdev_hard_start_xmit line=692 msg="enter IPsec interface-AZURE_VPN" id=20085 trace_id=125 func=esp_output4 line=897 msg="IPsec encrypt/auth" id=20085 trace_id=125 func=ipsec_output_finish line=532 msg="send to 83.140.160.1 via intf-port1" id=20085 trace_id=126 func=print_pkt_detail line=5494 msg="vd-root:0 received a packet(proto=6, 83.140.160.1:16105->192.168.1.1:179) from local. flag , seq 2878734237, ack 0, win 13980" id=20085 trace_id=126 func=resolve_ip_tuple_fast line=5569 msg="Find an existing session, id-0afcfab0, original direction" id=20085 trace_id=126 func=ipsecdev_hard_start_xmit line=692 msg="enter IPsec interface-AZURE_VPN" id=20085 trace_id=126 func=esp_output4 line=897 msg="IPsec encrypt/auth" id=20085 trace_id=126 func=ipsec_output_finish line=532 msg="send to 83.140.160.1 via intf-port1"  

[emnoc]

Could be a bug but why are you on 6.0.6  is my 1st observation?

Ken Felix

[Benoit_Rech_FTNT]

Hello,

I think you need to specify the interface in addition to the update-source.

config neighbor

edit "11.1.0.1"
set advertisement-interval 1
set capability-graceful-restart enable
set link-down-failover enable
set stale-route enable
set soft-reconfiguration enable
set interface "1-1-1-1-1"
set remote-as 65001
set route-map-out "NON_TRANSIT"
set connect-timer 1
set update-source "1-1-1-1-1"
next

Best regards

Benoit

[araatn]

Hi Benoit,

I've already done this ;)

FW_A_001 (bgp) # show config router bgp     set as 6000     set router-id 172.23.0.1     config neighbor         edit "192.168.1.1"             set ebgp-enforce-multihop enable             set interface "port2"             set remote-as 65011             set route-map-in "rm-AZURE-IN"             set route-map-out "rm-AZURE-OUT"             set update-source "port2"         next     end

[Toshi_Esumi]

I would suggest you have an IP on the tunnel interface and use it to neighbor with the other side. So that it's always reachable from the other end as long as the tunnel is up even when BGP hasn't been established. Otherwise, it's a "chicken or egg" situation.

[araatn]

Hi Toshi,

Actually I do not use an IP on the neighbor basically my tunnel has no IP address. Normally you don't need this for routed s2s vpn (for ospf or bgp), with other vendors like PA or Checkpoint work like without any problem. 

FYI:

I've also configured this on two other FW's (same configuration except the IP's & version) and it works like a charm.

But:

What I found out from those working FTG FW's is, they receive the SYN from the remote side then the BGP is established.  But the problem FW sends the SYN & does not receive the SYN.

What I assume is:

1) remote side is not ok

2) 6.0.6 has a bug with update-source -> why: with update-source configured on your BGP neigbor, it has to send the correct IP and the problem FW does not do it..

for 2 I do not find this in any bug documentation of version 6.0.6 so I don't know in which version it will be fixed....

[araatn]

Hi Ken,

My customer asked me to verify this, so I need to know in which version this could be fixed.

I assume this is a bug as well, but there is no verification found in known resolved or bugs..

[emnoc]

OP,

Upgrade to 6.2.x or the latest in 6.0.x and retest.

Ken Felix

[Toshi_Esumi]

Open a ticket at TAC to ask if it is/was a known issue, if you don't want to check all release-notes for 6.0.7 - 6.0.11 in the fixed problem lists.