Home Page › Forums › Network Management › VPN › Tunnel all traffics (everything) through LAN-to-LAN VPN
- This topic is empty.
-
AuthorPosts
-
August 10, 2014 at 9:14 am #44007
calvyn
MemberI’m new to ZeroShell.
Recently just configured LAN-to-LAN VPN between branch and main office.Just wondering, any possible to tunnel all traffics (include public internet traffics) from branch to HQ network?
I managed to bring up the tunnel between site specifics traffics (branch network to main office network vise versa) but public internet traffics will be off/split tunnel at ZS2 to internet…..
Base Topology:
(Main) Server => ZS1 => Internet <= ZS2 <= PC (Branch) LAN-to-LAN VPN Tunnel:
(Main) Server <=> ZS1 <=VPN=> ZS2 <=> PC (Branch)Desire internet traffic flow for branch:
(Branch) PC => ZS2 <==VPN==> ZS1 (Main) => InternetAugust 10, 2014 at 3:06 pm #53415redfive
ParticipantYou could achieve the goal by bridging the VPN with the ETHxx, and use as default gateway the ip address of the remote bridge, but , in this case , if for some reasons the internet of the main office goes down, the branch office’s clients, won’t be able to reach the internet as well,… second solution, could be … enable the net-balancer, give an high weight(16) to the real default gateway , and as second gateway (1), use the inner ip address of the vpn in the main office, NAT on the VPN00 (*) of the branch office, and a balancing rule to force the clients to use, as target-gateway, the ip address of the main office’s vpn……of course, never tried 🙂
(*) The NAT is for simplify the job, obviously you can also leave the packets as they are, and play with static routes.
RegardsAugust 14, 2014 at 1:47 am #53416calvyn
MemberHi, Redfive,
Thanks for reply.
I had tried both suggestion, but failed.
The VPN is UP. I had assigned IP (same subnet) to ZS VPN00 interface to both site.
At branch office, create Bridge00 to bind VPN00 and ETH00.
At HQ/main site, create Bridge00 to bind VPN00 and ETH02.When perform Check IP, ZS (both site) can ARP/PING to local site IP and remote ZS VPN00 IP.
From branch site ZS, cannot ARP/PING to any IPs/Devices behind HQ/Main site ETH02, but can ARP/PING VPN00 IP.
From HQ/Main site ZS, cannot ARP/PING to any IPs/Devices behind Branch site ETH00, but can ARP/PING VPN00 IP.Not sure what others else I had miss.
I had also tried below method, failed too.
http://artfiles.org/zeroshell.org/routed-IP-over-bonded-VPN.pdf
http://beusergroup.co.uk/technotes/index.php/VPN_BondingAny others idea?
Thanks.
August 14, 2014 at 10:49 am #53417redfive
ParticipantCould you explain in detail how the network topology has been developed ?
Eg, are both ZS the default gateways for the clients of the HQ and branch networks ?
Or there are other routers which perform this job, with some port-forwarding to the ZS machines and the ZS is a “simply” client of the existing networks ?
RegardsAugust 14, 2014 at 7:22 pm #53418redfive
ParticipantJust tried, on the fly, but in real topology:
ZS-A , vpn server, connected to the internet via usb dongle (pppp0) , ETH00 192.168.10.1/24, VPN00 inner address 10.20.20.1.
ZS-B, vpn client , connected to the internet (but behind a fw), ETH00 192.168.0.1/24, ETH00.12 192.168.12.1/24, ETH00.13 192.168.13.1/24, ETH00.14 192.168.14.1/24 , VPN00 inner address 10.20.20.2.
On ZS-A , a static-route, 192.168.12.0/22 via 10.20.20.2
On ZS-B , enabled the net-balancer, (LBFO) , as primary gateway the real default-gateway (weight 32), as ‘secondary’ gateway (weight 1) the ip address of the remote vpn peer, 10.20.20.1, then , in balancing rules, one rule , s.ip 192.168.12.0/22, target gateway 10.20.20.1. There is L3 visibilty among all private networks, and the clients of ZS-B are surfing the web via ZS-A.
tracert to google.com from a client of the 192.168.13.0/24 networkC:WindowsSystem32>tracert google.com
Traccia instradamento verso google.com [173.194.116.3]
su un massimo di 30 punti di passaggio:
1 2 ms 1 ms 2 ms 192.168.13.1
2 166 ms 147 ms 144 ms 10.20.20.1
3 292 ms 325 ms 375 ms 172.31.8.70
4 217 ms 195 ms 195 ms ^C
C:WindowsSystem32>Is enough playing a bit with static routes and, if needed, with some nat rules (for the clients which may belong to the network between Zs and the other fw) for obtain the result.
Regards -
AuthorPosts
- You must be logged in to reply to this topic.