This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

cannot complete inbound tcp connections over site-to-site VPN

I've completed site-to-site VPN setup with AWS using transit gateway using Sophos XG firewall.

topology

internal network (10.x.x.x) ------sophos-xg------site-to-site-vpn-AWS--------vpn-gw-----transit-gateway-----vpc (172.31.0.0/16)

what works:

- ping from internal network to vpc and ping from vpc to internal network

- outbound tcp session to AWS VPC

- traceroute from internal network to vpc

what doesn't work:

- traceroute from vpc to internal network

- AWS VPC tcp inbound connection into internal network

For the inbound TCP connection (test to port 9999), I can see the VPC on 172.31.x.x packet reaching the firewall on WAN interface 218.x.x.x. Internal network is 10.x.x.x ip address.

is DNAT rule required to make this work? I tried playing with it but haven't got it to work either.

Thanks.

This thread was automatically locked due to age.

Parents

0 LuCar Toni over 5 years ago

Actually i would recommend to (wait) and update to V18.

V18 will introduce Route Based VPN with VTI.

This will make your Setup much easier.

Is this a production environment or are you happy to try a Early Access Version of V18?
Cancel
Vote Up 0 Vote Down

Cancel
0 fustyler over 5 years ago in reply to LuCar Toni

Thanks for the reply.

This is for a production environment.

When is the expected release date of V18?

Is there any workaround for now to fix the issue?
Cancel
Vote Up 0 Vote Down

Cancel
0 LuCar Toni over 5 years ago in reply to fustyler

Route Based VPN Would not be a Workaround, it would be a better approach to this kind of VPN.

I guess something is blocking the traffic, maybe AWS or maybe XG.

You should Dump the traffic on XG and take a look, if the traffic is reaching XG.

Maybe try a drppkt on the Shell to see dropped Packets.
Cancel
Vote Up 0 Vote Down

Cancel
0 fustyler over 5 years ago in reply to LuCar Toni

The attached screenshot I showed from the logs displays the packet drops going to the wan interface of the internal network firewall.
Cancel
Vote Up 0 Vote Down

Cancel
0 FormerMember over 5 years ago in reply to fustyler

Hi fustyler,

When you say you are trying to connect into internal network using TCP connection, why we see traffic destination as public IP address? It shouldn't be the IP address of internal network? I am saying this because inbound interface is ipsec0 so the inbound traffic is routed through IPsec tunnel and XG firewall expects traffic destination as internal IP address from internal network matching IPsec connection profile.

Is there any NAT rule configured on AWS side?

Thanks,
Cancel
Vote Up 0 Vote Down

Cancel
0 fustyler over 5 years ago in reply to FormerMember

there is no NAT set up on the AWS side.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 fustyler over 5 years ago in reply to FormerMember

there is no NAT set up on the AWS side.
Cancel
Vote Up 0 Vote Down

Cancel

Children

0 KingChris over 5 years ago in reply to fustyler

Hi fustyler

How many SAs do you have configured in your ipsec policy on the XG?

On v17.x/v16.x, the XG is a policy based IPsec device. AWS only supports a single SA within your tunnel.

For traceroute problem, you would need to enable IGMP/PING on XG and AWS to allow it.

Please remember that you will need to create firewall rules.

Also inside your IPsec networks, you must make sure the far side is included in the configuration otherwise it will not route.

However I do agree with that you should utilize v18 and choose the option to use route based VPN.

Thanks!
Cancel
Vote Up 0 Vote Down

Cancel
0 fustyler over 5 years ago in reply to KingChris

firewall rules are in place to allow all traffic bi-direction as the first rule.

AWS confirmed IPSec tunnel was formed correctly after reviewing packet captures.
Cancel
Vote Up 0 Vote Down

Cancel