Site to site VPN routing additional subnetworks at Main server site
-
Hello All,
I have established site to site VPN AS follows below diagram, on remote main i need to access additional sub network of 192.168.0.0
On server configuration i addedpush "route 192.168.0.0 255.255.0.0";
but when i try to access that network i cant , did i missed something ?
please advice
Thanksclient BRANCH 172.16.1.0/24>>>>>>>>>MAIN server21x.x.x.x
|
|
21x.x.x.4 gateway
192.168.0.0/24 -
Diagram and question are unclear…. please re-draw network map and restate question.
Are you trying to access 192.168.0.0 on the client-side or server-side?
Post server1.conf and client1.conf.
-
Hello All,
I have established site to site VPN AS follows below diagram, on remote main i need to access additional sub network of 192.168.0.0
On server configuration i addedpush "route 192.168.0.0 255.255.0.0";
but when i try to access that network i cant , did i missed something ?
please advice
Thanksclient BRANCH 172.16.1.0/24>>>>>>>>>MAIN server21x.x.x.x
|
|
21x.x.x.4 gateway
192.168.0.0/24Your "diagram" shows 192.168.0.0/24 - so the push route should be:
push "route 192.168.0.0 255.255.255.0"
(that should not have broken anything)
a) Routing boxes need to know about subnets that are not locally connected:
MAIN server - make sure it has a route to 192.168.0.0/24 through 21x.x.x.4
21x.x.x.4 gateway - make sure it has a route to 172.16.1.0/24 through MAIN server 21x.x.x.xb) Traffic needs to be passed by any firewalls along the way:
Make sure that firewall rules on MAIN server and gateway allow traffic to/from all the subnets. -
Hello All,
I have established site to site VPN AS follows below diagram, on remote main i need to access additional sub network of 192.168.0.0
On server configuration i addedpush "route 192.168.0.0 255.255.0.0";
but when i try to access that network i cant , did i missed something ?
please advice
Thanksclient BRANCH 172.16.1.0/24>>>>>>>>>MAIN server21x.x.x.x
|
|
21x.x.x.4 gateway
192.168.0.0/24Your "diagram" shows 192.168.0.0/24 - so the push route should be:
push "route 192.168.0.0 255.255.255.0"
(that should not have broken anything)
a) Routing boxes need to know about subnets that are not locally connected:
MAIN server - make sure it has a route to 192.168.0.0/24 through 21x.x.x.4
21x.x.x.4 gateway - make sure it has a route to 172.16.1.0/24 through MAIN server 21x.x.x.xb) Traffic needs to be passed by any firewalls along the way:
Make sure that firewall rules on MAIN server and gateway allow traffic to/from all the subnets.Hi
Thanks for the answer , my main server siteA is aware and can ping 192.168.0.0 successfully
Now when i ping from 172.16.1.49 >>>>>fwbranch>>>>>>fwmain21x.x.x.1>>>>>>21x.x.x.4 i have replay and i can ping opposite
but when i ping for example 172.16.1.49 >>>>>fwbranch>>>>>>fwmain21x.x.x.1>>>>>>21x.x.x.4>>192.168.3.59 i get timeout
But i think the issue is on the branch side why when i do simple tracert test to 21x.x.x.4 i get routed trogh the tunnel networkC:\Users>tracert 21x.xx.xx.4
Tracing route to tunnel [21x.xx.xx.4]
over a maximum of 30 hops:1 <1 ms <1 ms <1 ms 172.16.1.3
2 118 ms 110 ms 111 ms 10.0.8.1 >>>>>tunnel network
3 113 ms 128 ms 122 ms host [21x.xx.xx.4]and when i do same to private network i can see i am not go trough the tunnel
C:\Users>tracert 192.168.3.59
Tracing route to 192.168.3.59 over a maximum of 30 hops
1 * * * Request timed out.
2 net-xx-x1-1x-1.cust.dsl.vodafone.it [xx-x1-1x] reports: Destination net
unreachable.Trace complete.
so i guess there is route push config i tried to put on server side
push "route 192.168.0.0 255.255.0.0";
and client side
route 192.168.0.0 255.255.0.0;
but still not working
please advice
Thanks -
Yes, the push route should work. There might be some confusion about the 192.168.0.0 subnet.
Your original diagram mentions 192.168.0.0/24
But your push route examples are using 192.168.0.0/16 and you are pinging to 192.168.3.59 - out of the /24 but in the /16.
I suggest double-check all settings and make sure "/16" "255.255.0.0" is being used everywhere for 192.168.0.0 - particularly the client conf file (it might have an old push route entry that is wrong?)
And try to ping/traceroute to something in the 192.168.0.1-254 range - if that works then you just have a subnet mask wrong somewhere preventing getting to the higher addresses. -
That's precisely why I asked for a better network map and more detail. We are also still waiting for configs.
-
Yes, the push route should work. There might be some confusion about the 192.168.0.0 subnet.
Your original diagram mentions 192.168.0.0/24
But your push route examples are using 192.168.0.0/16 and you are pinging to 192.168.3.59 - out of the /24 but in the /16.
I suggest double-check all settings and make sure "/16" "255.255.0.0" is being used everywhere for 192.168.0.0 - particularly the client conf file (it might have an old push route entry that is wrong?)
And try to ping/traceroute to something in the 192.168.0.1-254 range - if that works then you just have a subnet mask wrong somewhere preventing getting to the higher addresses.Hi
Thanks for the answer ,yes you right this is my mistake its 192.168.0.0/16 ,we have 16bit internal network ,any way the push and route where set correctly but still i don't have routing that LAN (192.168.0.0/16) yet, so when I am doing tracert to one of those ip's i can see that its not going trough the tunnel
I attached LAN diagram as requested by Marvosa
Thanks
-
I can't see a problem with your screenshots.
C:\Users\>tracert 192.168.3.59 Tracing route to 192.168.3.59 over a maximum of 30 hops 1 * * * Request timed out. 2 net-xx-x1-1x-1.cust.dsl.vodafone.it [xx-x1-1x] reports: Destination net unreachable. Trace complete.
That seems really odd. I guess this is from a client inside BRANCH 172.16.1.0/24. In the other successful traceroute, the first hop is the BRANCH pfSense 172.16.1.3 - that should be the default gateway for this BRANCH client. So why doesn't this tracert also go to 172.16.1.3 straight away?
Are there multiple routers at BRANCH? Maybe the default gateway is something else, and that other router needs to be told that 192.168.0.0/16 is reachable through the pfense VPN?
Let us know more about the network at BRANCH. -
I can't see a problem with your screenshots.
C:\Users\>tracert 192.168.3.59 Tracing route to 192.168.3.59 over a maximum of 30 hops 1 * * * Request timed out. 2 net-xx-x1-1x-1.cust.dsl.vodafone.it [xx-x1-1x] reports: Destination net unreachable. Trace complete.
That seems really odd. I guess this is from a client inside BRANCH 172.16.1.0/24. In the other successful traceroute, the first hop is the BRANCH pfSense 172.16.1.3 - that should be the default gateway for this BRANCH client. So why doesn't this tracert also go to 172.16.1.3 straight away?
Are there multiple routers at BRANCH? Maybe the default gateway is something else, and that other router needs to be told that 192.168.0.0/16 is reachable through the pfense VPN?
Let us know more about the network at BRANCH.Hi Phil,
You right they do have second gateway Internet Interface on same firewall , I did force all outgoing destination 192.168.0.0/16 go trough the gateway
fastwebnet.it [9x.xx.xx.xx]
interface where is tunnel is setup but still i get as follows bellow , tracert from host.
now i do see 192.168.0.254 right before the gateway but i don't know from where its coming since the internet interface is set directly with the static 9x.xx.xx.xx ip address
In addition when i am doing tracert from firewall itself i do see and answer from destination and also verified at diagnostic routes that route exist for destination.
ThanksC:\Documents and Settings>tracert 192.168.1.1
Tracing route to 192.168.1.1 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.0.254
2 12 ms 12 ms 12 ms 9x-xx-x-x.ipx0.fastwebnet.it [9x.xx.xx.xx]
3 12 ms 12 ms 12 ms 10.0.28.69
4 12 ms 12 ms 12 ms 10.0.28.69
5 12 ms 12 ms 12 ms 10.254.11.17
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 ^Ctracert from firewall
1 10.0.8.1 (10.0.8.1) 211.616 ms 205.635 ms 206.989 ms
2 2xx.xxx.xxx.4 (2xx.xxx.xxx.4) 208.586 ms 208.149 ms 209.119 ms172.16.1.3 link#2 UHS 0 0 16384 lo0
192.168.0.0/16 10.0.8.1 UGS 0 952 1500 ovpnc2Interfaces
WAN_FASTWEB [WAN_FASTWEB is up] 9x.xx.xx.xx 100baseTX <full-duplex>LAN [LAN is up]172.16.1.3 1000baseT <full-duplex>WAN_VODAFONE(DHCP) [WAN_VODAFONE is up]10.10.10.3 |100baseTX</full-duplex></full-duplex> -
Ok,
I think the mystery solved , but still not works :( , i discovered next hop right after external fw leg is 192.168.0.254 so this is why there is no routing to 192.168.0.0/24
but what more mysterious is when i do tracroute from firewall its go trough vpn tunnel ,but not the case from lan client side
Any ideaThanks
-
You should not use 'push "route…' and 'Local network' settings in preshared key setup - it doesn't work: http://doc.pfsense.org/index.php/Why_won%27t_OpenVPN_push_routes%3F
Clean up advanced options and 'Local network' on both ends and try the following:
Remote network: 172.16.1.0/24 - on the server side
Remote network: 192.168.0.0/16 (!) - on the client side. -
Ok,
I think the mystery solved , but still not works :( , i discovered next hop right after external fw leg is 192.168.0.254 so this is why there is no routing to 192.168.0.0/24
but what more mysterious is when i do tracroute from firewall its go trough vpn tunnel ,but not the case from lan client side
Any ideaThanks
IMHO, when you ping/traceroute from a LAN client, the packet goes first to your other gateway. That other gateway knows about 192.168.0.0/24 attached to (or close to) it. So it sends it there.
When you ping/traceroute from pfSense, it knows a route to 192.168.0.0/16 across the OpenVPN, so sends it across the OpenVPN.I am finding more and more, rule #1 of designing a private IPv4 network is, never use 192.168.[0-n].0 addresses (where "n" is maybe up to 10 or 20). Then you avoid conflicts with all the default private networks that get in your way when your network map expands.
I pick a "random" 10.n.0.0/16 and make /24s out of that - e.g. 10.73.0.0/24 10.73.1.0/24 …
IPv6 is much better, with a large chunk of "private" address space to randomly pick from.