We have an IPsec connection with our partner, due to increasing of traffic, SRX can not handle the encryption/decryption any more, so we decide to migrate to direct connections. I put both st0 interface and physical direct connection interface in the same security zone so I don't have touch exsiting security policies or NAT rules, for the migration, I thought I just deactivate the VPN and lift the BGP import filter so routing to partner side prefix will now go out of physical interface, everything should just work, easy enought right? not so much ... somehow TCP session can not be established from either direction after cutover, security flow session indicates that sessions were created by intitating connections from either side, but there is no return traffic. Here is the diagram
## Here is the show security session interface output when VPN was deactivated
for inbound traffic internal host 172.18.63.122 is statically mapped to 18.104.22.168, for outbound traffic internal host is PAT'd to 22.214.171.124 (if this internal host does not have static NAT address assigned)
Look at the inbound session, obviously SRX received TCP SYNC from partner, but seems that SRX did not receive SYNC-ACK from our internal host, but from the outbound session, SRX received TCP SYNC from internal host, but did not receive SYNC-ACK from partner side.
This is a pure networking layer routing changes, there is no application side configuration changes and both partner and I verifed that routing is correct, but the above two sessions controdict to each other. By looking at the flow session, I am not sure which leg is having problem, for example for the inbound session, we can conclude that inbound from partner to SRX works, but how do I know the return session failure is because of our internal host is not sending sync-ack to SRX, or SRX failed to send syn-ack to partner, or partner side received sync-ack but failed to send back to SRX? I unfortunately didn't have the luxury to take my time to do flow trace on my side during the short maintence window. Where else should I look further off line?
Since there is no return traffic it would appear the route from the remote site to 126.96.36.199 188.8.131.52 (and perhaps other addresses) is not being directed to your new physical link. Likely they route out the default gateway for the remote site instead.
Steve Puluka BSEET - Juniper Ambassador IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP) http://puluka.com/home
Thanks Steve, but look at the inbound session, we did receive packets on the new physical interface for partner intiated connections, so it appears that partner does have right routing to us. Both partner side source (184.108.40.206/25) and our side public addresses (220.127.116.11/29) fall into BGP prefix range we advertised to each other over the new connection.