Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[philippe44]

Hi - I have a problem with asymmetrical routing : my Dlink is default GW 192.168.2.1 and sends openVPN traffic to a server 192.168.2.203 on my LAN. The openVPN server assign 192.168.4.x addresses. To allow LAN computers to communicate with VPN client, I've added a route in the Dlink to route 192.168.4.x traffic to 192.168.2.203. This setup is fine and all LAN client can initiate a session with a VPN client. That does

192.168.2.x ==> 192.168.2.1 ==> 192.168.2.203 ==> 192.168.4.x
and on the return path
192.168.4.x ==> 192.168.2.203 ==> 192.168.2.x

The problem is that, as you can see, the route in is different from the route out. This not a problem when the session is initiated from the LAN side, but when any VPN client initiating the session, the path in

192.168.4.x ==> 192.168.2.203 ==> 192.168.2.x
but, on the return path
192.168.2.x ==> 192.168.2.1 == > dead

Packet is dead b/c Dlink router has not seen the opening of the session SYN, SYN-ACK, ACK and as a result, drop the "return" packets (this is similar to SPI filtering, but on the LAN side). I guess my question is probably more for Dlink people if they ever read this forum

- De-activating SPI does not change anything, so
- Could you add a feature that enables "triangle route" (other routers do) or at least could you not drop packets that are using the scheme I explained above ?
- Last but not least : adding a manual route on the LAN side of your router is feasible but is a hack (by default, only WAN side route are available) - can you change that too ?

PS : I know I can add a route in my LAN client to send 19.268.4.x to 192.168.2.203 (and it works), but changing all clients is a pain. I've also confirmed that the Dlink sends ICMP_redirect packets to the LAN client that sends 192.168.4.x packet to it, indicating that there is a better route, but most clients (including Win7) ignore ICMP_redirect for security reasons - so this is not a solution neither

Thanks

[FurryNutz]

Link>Welcome!
What Hardware version is your router? Look at sticker under router.
Link>What Firmware version is currently loaded? Found on routers web page under status.
What region are you located?

Be aware that Rev B model routers do not support lookback which could be the case here.

[philippe44]

Link>Welcome!
What Hardware version is your router? Look at sticker under router.
Link>What Firmware version is currently loaded? Found on routers web page under status.
What region are you located?

Be aware that Rev B model routers do not support lookback which could be the case here.

Thanks for answering

HW rev B, FW 2.07NA - I saw there is a 2.10 but it does not say anything about any change is this domain

I don't think this is a loopback problem, but really the fact that when the session is VPN->LAN, the DLink does not see the session opening, so he has no state when the packet return from LAN->VPN. As said, when the session is initiated by the LAN (LAN->VPN), everything works fine and the Dlink does his job of re-routing outgoing packets to the VPN server that sits inside the LAN, although they sit on the same subnet

[FurryNutz]

Are all or most of the devices connected to the 655 router in back?
Any use of a external switch could be of help.

I presume that it's possible that this kind of route configuration might not be supported some of DLinks routers. Even though other mfr routers may handle this kind of configuration, not all Mfr are the same nor is the HW. Most home and small business routers are mainly meant for just the average home user. Getting into more advanced and complex network configurations is probably meant for a different class router, i.e. business or enterprise.

I recommend that you phone contact DLink support, try level 2 or higher and ask them about this and see if maybe they can help you, if not, ask them if there is any DLink router that would be better suited for your needs.


Let us know what they say.

[philippe44]

I've finally decided to fix the other machines so that they allow ICMP_REDIRECT packets. I know there is potential security flaw here, but this is all on my LAN that is correctly protected, so low chance to have issues. I don't think I'll call Dlink support as this is probably a too specific problem for them to care about

Thanks for your help

[FurryNutz]

Glad you go it working for your needs.
Enjoy.