IPsec Tunnel Is Up but the Oracle Handshake Fails
An online retailer connects its on-premises Juniper SRX345 to an AWS VPC with a route-based IPsec VPN using two tunnels and eBGP. On-premises uses 10.50.0.0/16; the VPC uses 10.60.0.0/16. BGP is Established on tunnel 1 only; tunnel 2 is up but BGP is Active. The on-premises SRX has a default route to the internet and a static route for 10.60.0.0/16 to st0.0. AWS route tables point 10.50.0.0/16 to the virtual private gateway. Monitoring shows that on-premises servers can reach a web server in AWS, but the AWS web tier cannot open a TCP connection to an on-premises Oracle listener on 10.50.20.15:1521. AWS VPC Flow Logs show SYN packets accepted from the web tier, but no SYN-ACK is observed. A recent firewall change added a more-specific route for 10.60.10.0/24 through the internet firewall for a SaaS integration. The team wants to add a static route for the AWS web subnet on the SRX and call it done.
1. Why can on-premises initiate to AWS while AWS cannot complete a TCP handshake to the Oracle listener? What is the most likely routing fault, and why is adding a static route for the AWS web subnet a weak fix?
Read the worked answer
The SYN reaches the Oracle listener but no SYN-ACK returns, so the forward path works and the return path does not. The likely fault is the more-specific 10.60.10.0/24 route pointing at the internet firewall. Traffic from 10.50.20.15 to 10.60.10.x follows that route, bypasses the IPsec tunnel, and is dropped or translated differently. Adding a static route for only the AWS web subnet treats one prefix, can conflict with BGP, and may create asymmetric routing for other subnets. Check show route 10.60.10.0/24, show security flow session, and the SRX policy for 10.50.20.15 to 10.60.0.0/16 on TCP 1521. Fix by removing or redirecting the more-specific route to st0.0, or use policy-based routing only if the SaaS integration truly requires the internet path. Then confirm the AWS route table and security group allow the return traffic.
2. What verification steps would you run before changing SRX policy or adding routes?
Read the worked answer
Verify the actual return path first: on the SRX run show route 10.60.10.0/24, show route 10.60.0.0/16, show bgp summary, and show route receive-protocol bgp <peer> to confirm what AWS advertises and what the SRX prefers. Use show security flow session for the failed tuple to see whether a session exists and how it closes; a SYN without SYN-ACK often points to return routing or policy. On AWS, confirm the VPC route table, virtual private gateway propagation, network ACLs, and security groups. Capture traffic on both tunnel interfaces if possible. Only after confirming the return path should you change policy, because adding a permit for TCP 1521 without fixing routing will not complete the handshake.
3. Tunnel 2 is up but BGP is Active. What are the likely causes and the configuration checks?
Read the worked answer
An Active BGP state means the SRX is trying to establish TCP 179 but the peer is not completing it. Common causes are a wrong neighbor address, wrong AS number, missing BGP host-inbound traffic on the st0.2 interface, a security policy blocking TCP 179, or authentication mismatch. Check the AWS tunnel details for the inside addresses and ASN; the SRX must peer with the AWS tunnel inside address, not the public endpoint. On the SRX, verify show configuration protocols bgp, the st0.2 zone host-inbound services, and show security flow session for port 179. Also confirm both tunnels use the correct inside /30 and that the SRX has a route to the peer. Fix the mismatch, then verify show bgp summary reaches Established before relying on multipath.