Hi there,
thanks in advance for all your help! I'm a little bit new to all the routing stuff, so please appologize me for maybe stupid questions.
First of all, I managed to install openWrt on my Linksys WRT3200ACM for my standard (yes I know, ther is no standard) home network.
The short network layout is: An A1 Router/Modem is connected to the internet. There is only one RJ45 cable from this Modem to my Linksys WAN port. My complete Home network is connectied to the Linksys with same priorities (Cell phones/Notebooks via Wifi, Raspi acting as NAS, Desktop PC via LAN.
Also I added a SQM QOS management successfully as well as a guest WIFI which is not able to connect to the Home network, just to the internet.
Everything worked fine for me, but then:
Since the Corona thing, we all had to go to home office and I have to connect with my Company notebook (connected to the Linksys as well) via some sort of VPN to my company.
The strange thing is, that if the Notebook is connected via WIFI, everything works fine (except the WIFI has poor connection in my home office). Now if I use the RJ45 cable (internet works fine), the VPN is not working because server side detects a IP change between tunnel request and connection. So the server disconnects me for security reasons (possible man in the middle attack).
As far as I found out, WIFI and eth interfaces should be bridged (eth 0.1, radio2.network1, wlan0, wlan1).
Therefor I have no idea why WIFI and LAN acts different.
Any hints or suggestions where to start my search, or what could be the reason for this behaviour?
It depends on the VPN implementation.
For example my Cisco Anyconnect was able to reconnect without issues or even asking again for passcode after 20 minutes from when I suspended the laptop and commuted from work to home.
But yes the lan and wifi are bridged and the public IP will be the same.
So all in all, if you didn't accidentally connect via another public IP (3G/LTE tethering, neighbournet, etc) the public IP will be the same. If the server disconnects you maybe the settings are too tight and don't allow for missed keepalives, or maybe your client even will disconnect if it senses that connection was lost.
Hello, thank you for your answers and suggestions!
I contacted my company support team and they told me about the IP adress switch which leads to a server side close of the connection. (verry tight VPN config, but not discussable in a big company).
Since they told me it is a router configuration, I get not so much support from them, even if the guy on the phone tried to help, but was not familiar with openwrt.
The strange thing is, that I don't have the IP address switch if I'm in the WLAN, so I'm thinking of a misconfiguration of the bridging between ports and WLAN.
If I understood correctly, if I bridge WLAN and Ports, they should act exactly same.
I attach the bridge configuration:
What confuses me is, that can bridge only the VLAN (eth0.1) and not the Switch itself (eth.0).
If I select eth.0, I cannot connect to the router via cable any more and the router switches (thanks to this excelent feature) automatically back to the previous setting.
You must use eth0.1, because that is how the switch is configured by default on that router. Also, the bridge seems correct, I do not see how the interfaces could act differently.
Perhaps you could connect the computer by wire then by wifi, and see if the computer gets a different configuration from the router.
Ok thank's,
I did a ipconfig /all for both Wifi and cable connection.
Except the different IP adress (bun in the same range) the information (Gateway, etc... ) is exactly the same.
I'm not sure if "ipconfig /all" shows everything needed to verify the configuration?
You get different addresses because each interface has its own MAC address. Get the MAC address from the wired card in the laptop, and assign to it a fixed address on the router, the same address that you got with the wireless connection.
You could try to assign the same IP in wifi and cable with static leases. This way when you go from wifi to cable, your lan IP will remain the same. Hopefully the VPN will be more tolerable to this.
Just be careful not to connect on both wifi and ethernet.
Mhmm...
The problem is not, that I get a new IP adress if I change from WIFI to cable, the problem is, that it seems that I get a new IP assigned during the connection attempt of the VPN. (No change of the connection type).
If I connect via cable directly to the A1 modem, it works. (But this is not possible in my office)
Also it works if I connect via WIFI to the Linksys.
So the router is somehow acting different between connection of cable or WIFI, even if they should be bridged.
Can you please also check my VLAN settings? I'm still confused that I have to bridge the VLAN eth port, not the port itself:
(I also tried to "enable VLAN functionality" but there seems to be no change!)
THX!
Since you have two eth interfaces, you can configure both of them as untagged, and use ethx instead of ethx.y. However, I am convinced that your current config is correct, and this has nothing to do with your issue.
I would try to investigate what is happening on the laptop and what is the VPN client detecting.
Hello Eduperez,
thank you for your answer. The current switch setting is something I really dont understand.
I watched some videos of tagged, untagged, etc...
But I have no clue why I need to "virtually" route the traffic via the CPU.
What happens if I delete the second row and set everything to untagged?
Since I don't want to use the VLAN I could directly connect the WAN to LAN isnt it?
Or do I need to route traffic through the CPUs to force them to pass the QoS process?
So what happens if I use this setting?:
Hello trendy,
glad that I did just a screenshot and no real test.
Actually I would like to get rid of the VLAN, since my LAN and WIFI are bridged, but as described, I have troubles on the LAN and not on the WIFI. So I would like to remove everything which is "different" in LAN than in WLAN.
The only thing I can imagine is, that I have a VLAN configured on the ports but no VLAN in the WIFI.
So you think that might work?
Yes, you can mark as "untagged" both CPU ports on the switch configuration, and then use ethx instead of ethx.y on the network configuration. But you cannot remove the second VLAN, you need one for LAN and another one for WAN.
Ok, Ok, you are totally right, the bridging is not the issue!
I got in contact with my support team today and asked for the IP adresses which are involved in this incident. The out come was a logging entry that looks like:
routemon.cpp:599 - 'rmon' Unauthorized new route to 192.168.5.0/192.168.5.100 has been added (conflicts with our route to 0.0.0.0), disconnecting
192.168.5.x is my guest wifi on the linksys router.
Since no client is connected to the guest wifi now, I have no idea which device 192.168.5.100 might be.
Before I simply deactivate my guest wifi, any ideas what misconfiguration could lead to changing the route table to the guest network?
THX
So, small update!
Most important, it works now, I have a successful connection!
Thanks for all your support and help!
It also is important to find out that something is NOT the issue, so you know that you have to search somewhere else!
I had to deactivate the routing of the guest network (see below).
You might double check to make sure that your computer does not have the SSID/password saved and allowing an auto-connect to your guest network. Conversely, hopefully you do have your trusted wireless LAN SSID/password saved. You can set the priority and/or delete the guest network.
Assuming your wired connection is the trusted LAN, and your wifi connection was hitting the guest network, the entire network changes (not just the IP address). I suspect that if the VPN connection was active during the transition (or attempting to reestablish a connection if there is a break in overall connectivity as wired goes down and wireless comes up), it could throw an error since the new network is not expected. If you disable the VPN entirely and then make the transition to your guest wifi network, it might not throw the error.
I don't know if you would get that error if the wifi picks up on your trusted LAN since you'll still be adding/changing an IP address on your computer (but your route will not change since you're still on the same network).
Just to make it clear, you have merely blocked on firewall the dhcp and dns. If you didn't change anything else, one can connect to the guest, configure settings manually and surf the net.
I agree with @psherman that most likely your laptop has saved both guest and normal wifi and was jumping from one to the other.
Depending on the server implementation such transitions can be allowed. I have commuted from work to home with the laptop switched on and VPN server didn't kick me out when I unplugged the ethernet moved to 4G and then back to ethernet at home.
Mhmmm... ok, understood.
There is one additional info regarding my company owned notebook:
There is a software based blockage of the WIFI if a network cable is connected.
So there might happen something like this:
1: Connection to VPN is established
2: during start of the connection, eth is switching from "normal" to "VPNed" => network is refreshed (I can see a reloading of all icons on desktop, it seems there is more than just a VPN)
3: The VPNed network is not detected by the wifi blocking software for some seconds.
4: WIFI which is up again is connecting to the guest network
5: VPN server detects the wifi guest IP and closes connection again...
sounds strange but logically.
This means also, If I would switch of wifi completely on my Notebook it should work.
I will do this tests tomorrow and come back to you.
If this would be the sollution, it would be dammed easy
To prevent unintentional wifi connection, use the rfkill "airplane" switch on the laptop or click the wifi icon in the status bar and tell Windows to forget both wifi networks.
You could try relocating the router or adding an AP to get a better wifi signal where you will be using the laptop. Just moving the router to a high shelf instead of floor or desk height can improve wifi coverage in a house considerably.
