Timeline for VPN gateway in custom route table fails
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 27, 2023 at 18:18 | history | edited | A.B | CC BY-SA 4.0 |
deleted 5 characters in body
|
| Apr 27, 2023 at 18:14 | comment | added | A.B | @simonw also, while this is needed in some setups, I wouldn't expect to have a directly attached LAN 10.10.10.0/24 requiring a gateway in the same LAN. if 10.10.10.0/24 is on eth0, then that would be simply 10.10.10.0/24 dev eth0. Else even if that still works, 10.10.10.1 will probably start issuing ICMP redirects to tell the destination is directly reachable (or if 10.10.10.1 is the local system itself, this has just no effect). | |
| Apr 27, 2023 at 18:09 | history | edited | A.B | CC BY-SA 4.0 |
shorten a little bit.
|
| Apr 27, 2023 at 13:09 | comment | added | A.B | @simonw Yes you got it. It would be a problem if two different systems using the same source address (obviously not a public one) are only differentiated from the interface they send packets through and reach the same destination. As you confirmed things I'll edit it a little later but will still leave something in place in case it can help other readers with other use cases. | |
| Apr 27, 2023 at 10:39 | comment | added | simonw | Fab, thanks @A.B ! I've added the route '10.10.10.0/24 via 10.10.10.1' to both tun0/1 tables, now traffic returns as expected. If I understand your additional remark, there's a problem if any services are exposed via the VPN? Fortunately that's not the case and connections will always be outbound. Am I understanding that correctly? | |
| Apr 27, 2023 at 10:35 | vote | accept | simonw | ||
| Apr 26, 2023 at 21:40 | history | edited | A.B | CC BY-SA 4.0 |
LAN routes are probably with eth0 and eth1
|
| Apr 26, 2023 at 21:31 | history | answered | A.B | CC BY-SA 4.0 |