External supplier network not reachable through vpn connection between branch and main office

Question

Hi, im new to Sophos and just ran into a problem. I hope someone can help me with it.

We have 2 sites, one main Office (Sophos 1) and a brance office (Sophos 2). The main and branche office are connect with a site-to-site vpn. This is working fine.

At the main office we have a layer 2 connection with a supplier. (eth6) and we have to connect to there application servers on ip 172.20.20.1 and 2. From the main office this is working like a charm. Ping and tracert reply and the application is working.

To get this work we had to ad a Route in the Sophos so everything going to 172.20.20.1 and 2 is routed through gw 10.224.0.162 and leaving from interface 6. The supplyer has set the routes on there site. They made a route for the whole 192.168.0.0 sub to 10.244.0.167.

Tracing route to 172.20.20.1 over a maximum of 30 hops

1     *        *        *     Request timed out.
2    <1 ms    <1 ms    <1 ms 192.168.1.250
3     2 ms     2 ms     2 ms 10.224.1.163
4     3 ms     3 ms     3 ms 10.221.1.133
5     4 ms     3 ms     3 ms 10.224.1.101
6     3 ms     3 ms     3 ms 172.20.20.1

Trace complete.

When I try to reach the supplier servers from the branchoffice I got no reply on my ping. Myy trace directly give me the source address as second hop, instat of the whole list of routers I got when I do it from the main office as above.

Tracing route to 172.20.20.1 over a maximum of 30 hops

1    <1 ms    <1 ms    <1 ms 192.168.4.254
2     7 ms     7 ms     7 ms 172.20.20.1

It looks like the route back cant be found. I added the 10.224.0.160/28 network to my remote and local nw in the site-to-site vpn for testing and was able to ping and trace the first hop address from the main office (10.224.0.162) with success. The strange thing is that when I now trace 172.20.20.1 again I got first my Sophos, what I expect, second 172.20.20.1, and then 10.224.0.163....

Tracing route to 172.20.20.1 over a maximum of 30 hops

1    <1 ms    <1 ms    <1 ms 192.168.4.254
2     7 ms     7 ms     7 ms 172.20.20.1
3     9 ms     9 ms     9 ms 10.224.0.163

I did some packet trace, and see that my ping request is leaving the interface to the first hop, and that’s it.

Console > tcpdump -i eth5 dst or src host 192.168.4.150
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth5, link-type EN10MB (Ethernet), capture size 65535 bytes
21:25:49.685604 IP 192.168.4.150 > 172.20.20.1: ICMP echo request, id 1, seq 15596, length 72
21:25:49.687595 IP 10.224.0.163 > 192.168.4.150: ICMP time exceeded in-transit, length 36
21:25:53.538119 IP 192.168.4.150 > 172.20.20.1: ICMP echo request, id 1, seq 15597, length 72
21:25:53.540113 IP 10.224.0.163 > 192.168.4.150: ICMP time exceeded in-transit, length 36
21:25:57.538075 IP 192.168.4.150 > 172.20.20.1: ICMP echo request, id 1, seq 15598, length 72
21:25:57.540099 IP 10.224.0.163 > 192.168.4.150: ICMP time exceeded in-transit, length 36
21:26:01.540123 IP 192.168.4.150 > 172.20.20.1: ICMP echo request, id 1, seq 15599, length 72
21:26:05.538548 IP 192.168.4.150 > 172.20.20.1: ICMP echo request, id 1, seq 15600, length 72

I then started a tcpdump on eth4 where my vpn is connected with the branchoffice

Packetdump on eth4, thisi my internet interface where the vpn is leaving to the remote office and I got the follow entries. The entry in yellow are different than when I ran a tcpdump when tracing a internal address.

22:00.072779 IP 192.168.4.150 > 172.20.20.145: ICMP echo request, id 1, seq 15584, length 72
21:22:01.077339 IP 192.168.4.150 > 172.20.20.145: ICMP echo request, id 1, seq 15585, length 72
21:22:01.079579 IP 10.224.0.163 > 192.168.4.150: ICMP time exceeded in-transit, length 36
21:22:05.038342 IP 192.168.4.150 > 172.20.20.145: ICMP echo request, id 1, seq 15586, length 72
21:22:05.040639 IP 10.224.0.163 > 192.168.4.150: ICMP time exceeded in-transit, length 36
21:22:06.094915 ARP, Request who-has 192.168.4.150 tell utm, length 28
21:22:06.095331 ARP, Reply 192.168.4.150 is-at 88:f0:31:ff:3b:80 (oui Unknown), length 46
21:22:09.038652 IP 192.168.4.150 > 172.20.20.145: ICMP echo request, id 1, seq 15587, length 72
21:22:09.040884 IP 10.224.0.163 > 192.168.4.150: ICMP time exceeded in-transit, length 36
21:22:13.039432 IP 192.168.4.150 > 172.20.20.145: ICMP echo request, id 1, seq 15588, length 72
21:22:17.038534 IP 192.168.4.150 > 172.20.20.145: ICMP echo request, id 1, seq 15589, length 72

I also started a tcpdump on the branchoffice but noting.

I hope someone can help me with this.

below i tried to draw the situation.

This thread was automatically locked due to age.

BAlfson · Accepted Answer

Hi, Jacky, and welcome to the UTM Community! 
 When the VPN is correctly configured, WebAdmin automatically creates all the necessary routes. Does Hub and Spoke Help make it clear what needs to be changed? 
 Cheers - Bob 
 PS I can tell you're a talented networking guy, probably a CCIE, and that will be a big advantage once you learn the WebAdmin metaphor. WebAdmin manipulates databases of objects and settings. The configuration daemon consults these databases and writes the lines of code that make the UTM work. The middleware executes the code. Scan the Rulz post to get started understanding some other gotchas when using WebAdmin.

JackyKornet · Answer

Hi Bob, 
 
 Thanks for your quick reply. I read the article, and dubble check the vpn connection. Everything must be good at our site. 
 The connection is now working by the old VPN Connection to there old IT Company. 
 
 I have made a test setup and got the same result. So i calld the software deliverer. They still set that everething is right at there side... but a minute later i get a call from our customer that it is now also not working anymore by the old way.... i did nothing :P 
 I think they changed the route to, what the say already was, our gw at the moment i speak to them on the phone, and broke the connection to the old it company..So we found the problem. 
 
 Thanks for you reply again. this case is closed for now :) 
 bye