Site to Site VPN

Michael,

If you have created LAN to vpn and viceversa firewall rules, create nat rules using cli:

Regards

Ok, I have verifed the Firewall Rules exist and that the routes do exist to the two networks I am attempting to connect to but i am confused on the proper setup of the NAT rule.

Hopefully here is information that will help you help me.

Local network - 192.168.105.0/24

Remote Network 1 - 192.168.200.0/24

Remote Network 2 - 192.168.201.0/24

Local Device Internal - 192.168.105.195,.253,.254

Is there anything else that is needed as i am confused on the actual NAT rule setup as I may need to talk to many IP's in both remote networks.

Michael,

can you share your VPN settings? Make sure both Firewall have the same Site-to-site configuration apart local and remote networks (they must be in reverse order).

Thanks

Below are the pictures as requested, some information has been removed but the core information is there.

HI Michael ,

LAN to VPN rule - No NAT

VPN to LAN rule - NAT MASQ apply

Try these settings and reconnect the IPsec VPN tunnel

I have tried multiple NAT options and still nothing.

Now just to confirm a site to site VPN will work with the home license correct?

Disable all NAT options on firewall rules.

Add a network definition 192.168.200.0/23  and use that on the VPN instead of the 2 you're using now.  Do this on remote VPN side as well.
Now all traffic goes over single tunnel, instead of a separate tunnel for each subnet

So I removed the 192.168.201.0 network all together as I don't need it now but still it doesn't work.  I also did remove NAT from the firewall rules.  I had no issues with this on the Sophos UTM home version so I don't understand where my problem is now.  Both sides see the VPN as being up but no traffic will pass.

So I removed the 192.168.201.0 network all together as I don't need it now but still it doesn't work.  I also did remove NAT from the firewall rules.  I had no issues with this on the Sophos UTM home version so I don't understand where my problem is now.  Both sides see the VPN as being up but no traffic will pass.

...try to use predefined AES128 policy and cofigure same policy settings on Baracuda, no nat on fw rules for vpn/lan traffic.

Is there a place somewhere to see encrypted/decrypted packet counts?
At least you can use tcpdump on WAN interface to see if you got ESP or udp4500 packets flowing (=IPSEC encrypted traffic)

Ok so I have made some advancements.  I can see that I am in fact sending traffic to the Barracuda firewall.  However it is not sending any traffic back to me.  So it looks like this is a Barracuda issue.  I will be opening a ticket with them tomorrow to look into the issue.  Hopefully once i have this working I will post what if any additional changes were needed as well as my final configuration settings.

Ok so after dealing with Barracuda support for over an hour we had a successful VPN connection that was passing traffic and then two hours later the Sophos lost the VPN connection and it is back to not working. Traffic is being sent from the XG to the Barracuda and the Barracuda is sending traffic back however the XG doesn't see the traffic coming back yet it has no issues with getting the VPN up and running.

So I am not back to square one but I still don't have a working VPN on the XG that did work on the UTM without any issues.

HI Michael, 

If the tunnel is established and the Barracuda is sending the traffic to the XG appliance , you may need to run the packet capture on the console or on  UI for the same command . 

Console > tcpdump 'host <Remote network> or port 4500 or port 500

I have done that i see the following when looking at port 500:

20:53:46.962626 Port2, IN: IP "REMOTE IP".500 > "LOCAL IP".500: isakmp: phase 2/others ? inf[E]
20:53:46.962987 Port2, OUT: IP "LOCAL IP".500 > "REMOTE IP".500: isakmp: phase 2/others ? inf[E]

There is nothing for port 4500.

HI Michael, 

Could you check if you are receiving the ESP packets from the remote location , command is 

console> tcpdump 'host <Remote Public address> 

Same exact results just port 500, and yes I ran the command without defining the port option.

Also both sides are reporting the tunnel as being up.