only default GW and VPN server reachable from VPN Client ?

philippe44

Hi - I've a pretty simple setup

- default GW is 192.168.2.1 (DIR-655) and redirects port 1194 to the OpenVPN server that ...
- runs on another machine 192.168.2.203 (NAS) that ...
- allocate 192.168.4.x to VPN clients and ...
- pushes a route to clients to access to 192.168.2.0 and ...
- activates ip forwarding (and tun)
- default GW has a route to redirect 192.168.4.x network to OpenVPN server 192.168.2.203 on the LAN

I'm connecting either through an iPhone with VoD or through a Windows client. Connections work fine, including on demand mode for iPhone, I can access everything on the NAS.

But Clients can only see the default GW and the OpenVPN server (NAS) on the LAN, nothing else.
Using Wireshark, ping from the LAN is re-routed to Clients and is ack correctly (tracert is correct) but ping from the client to the LAN only work for default GW and OpenVPN server. Ping from VPN client to other machines are correctly transmitted and arrive on the LAN (captured by wireshark - so I assume forwarding works), but other machines never answer - huh ?

Thank you

maikcat

hi there,

Ping from VPN client to other machines are correctly transmitted and arrive on the LAN (captured by wireshark - so I assume forwarding works), but other machines never answer - huh ?

next step,run wireshark on other machines and see what is going on...
do "other machines" have firewall enabled?

Michael.

philippe44

maikcat wrotehi there,

Ping from VPN client to other machines are correctly transmitted and arrive on the LAN (captured by wireshark - so I assume forwarding works), but other machines never answer - huh ?
next step,run wireshark on other machines and see what is going on...
do "other machines" have firewall enabled?

Michael.

Hi Michael - Thank for helping. Obviously I'm stacking a few different issues here.

- My Windows box had a firewall issue that prevented it from accepting incoming non-local traffic (from 192.168.4.x). Adding the right rules solved that, it is now answering to ICMP packets, although this still does not work (see below), but at least it DOES answer now
- My Linux boxes did not have firewall and did answer the ICMP request but nothing returns back to the VPN client. All boxes are "equal" now

(just for memory, my config is : local network is 192.168.2.x, 192.168.2.1 is default GW, 192.168.2.203 is a NAS acting as the OpenVPN server and 192.168.4.x is the VPN network)

(for recollection, an ICMP request FROM the Windows box reaches correcty the VPN clients and receives and answer - only the other way around was/is a problem)

- So, as expected, when receiving a ICMP from 192.168.4.x, the Windows box now answers and (as expected) sends the packet to 192.168.2.1 that is supposed to forward it back to 192.168.2.203.
- What seems to happen is that the default GW answers by an "ICMP redirect" telling to the Windows box that there is a better route to 192.168.2.203 than going through the GW. This makes sense but what seems to happen is that not only the default GW answers with the "redirect" but also does NOT do the job of forwarding
- Adding manually a route in the Windows box that says that 192.168.4.x must be reached through 192.168.2.203 is a solution that I tested successfully, but I don't want to do that on all my boxes on my local network

So I guess my question to network gurus is "am I doing something wrong with my config where the default GW on 192.168.2.1 is supposed to forward 192.168.4.x to 192.168.2.203 or is this a bug in the routing of the default GW (a DIR655) regarding handling of "better route" option"

Thanks

maikcat

What seems to happen is that the default GW answers by an "ICMP redirect" telling to the Windows box that there is a better route to 192.168.2.203 than going through the GW. This makes sense but what seems to happen is that not only the default GW answers with the "redirect" but also does NOT do the job of forwarding

AFAIK in many cheap routers static routes dont work as expected.... 🙁

how about setting up your pcs to have default gateway the openvpn server itself
and let him do the routing...

Michael.

philippe44

maikcat wrote
AFAIK in many cheap routers static routes dont work as expected.... 🙁

how about setting up your pcs to have default gateway the openvpn server itself
and let him do the routing...

Michael.

Yeah - unfortunately I'll have to do something like that but it will be complicated as the openvpn server is probably not capable of handling all the traffic (this is a "modest" NAS). Will have to change some of network topology and have another NAS declare itself as the default GW (acting properly with this redirect issue) then forwarding the internet traffic to the real internet GW - might have to change also who is DHCP server ... painful

philippe44

okay ... so I took the time to change my network configuration and I can confirm that the problem was the Dlink router ... so painful.

I wasted a lot of time on that b/c the tracert/ping/wireshark to a VPN client was nicely showing
LAN_client -> Dlink(def GW) -> NAS(openvpn) -> VPN_client (proof that the Dlink was doing its "special route" work
as well as the return path
VPN_client -> (through openvpn NAS) -> LAN_client

So obviously I was assuming that the Dlink was doing its job properly but in fact on the other direction what is happening is
VPN_client -> (through openVPN NAS) -> LAN_client
and the return path
LAN_client -> Dlink(def GW) (dead)

This is really strange is that the Dlink fails _only_ on the return path,although this is the same route to take ... anyway, maybe again some guru can give me a rational answer :-)

Crap ! 🙁

philippe44

philippe44 wrote
So obviously I was assuming that the Dlink was doing its job properly but in fact on the other direction what is happening is
(1) VPN_client -> (through openVPN NAS) -> LAN_client
and the return path
(2) LAN_client -> Dlink(def GW) (dead)

This is really strange is that the Dlink fails _only_ on the return path,although this is the same route to take ... anyway, maybe again some guru can give me a rational answer :-)

Crap ! 🙁

mmmh ... thinking a few minutes. My router has a firewall with SPI. Could it be that because it did not see the SYN,SYN-ACK,ACK of part (1) that went through the NAS, then that packet LAN -> Dlink (def GW) is filtered as it does not correspond to any session ??? need to re-read my TCP/IP manual .... The initial way works obviously as this is the session opening so the LAN_client will set the SYN bit properly ?

maikcat

i am not dlink guru,but in zyxel routers/firewalls there is a thing
called "triangle route" in firewall settings which does exactly what you mention...

Michael.

philippe44

philippe44 wrote
mmmh ... thinking a few minutes. My router has a firewall with SPI. Could it be that because it did not see the SYN,SYN-ACK,ACK of part (1) that went through the NAS, then that packet LAN -> Dlink (def GW) is filtered as it does not correspond to any session ??? need to re-read my TCP/IP manual .... The initial way works obviously as this is the session opening so the LAN_client will set the SYN bit properly ?

ok ... I'll take that back, this is ICMP not TCP ... but it seems that routers can do similar with ICMP header (request/reply)

philippe44

You are right this is a triangle route problem (as usual, writing correctly the description of a problem is in 90% of cases solving it) and Dlink router will filter out all these packets silently, could not find any option to allow triangle route. Too bad :-( but at least I improved my IP knowledge :-)

Thanks

maikcat

you welcome 🙂

Closing topic

Michael.