interner Host mit externen vpn client lässt sich nicht mehr routen

[badsmoke]

Hallo ich habe mehrere Netzwerke LAN + test1 ....test2 , namen sind egal ;-)

wenn ich im netzwerk test1 in einem gerät/vm eine vpn verbindung zu einem externen vpn server starte, kann ich mich von LAN nicht mehr auf dieses gerät verbinden.

Auf dem gerät bleibt aber die default route über die opnsense erhalten, deswegen geh ich davon aus das die opnsense irgendwas blockt?
Auf dem gerät funktioniert alles namensauflösung/internet über die opnsense
Die geräte haben ubuntu installiert ich geh davon aus das das gleiche problem auch bei windows besteht.

Code Select Expand


      WAN / Internet
            :
            : PPPoE-Provider
            :
      .-----+-----.
      |  Gateway  |  (Router)
      '-----+-----'
            |
        WAN | IP or Protocol
            |
      .-----+------.   anderes Netz   .-------------------------.
      |  OPNsense  +-----------------+ VMs   mit vpn Client |
      '-----+------'   10.8.0.0/24   '---------------------------'
            |
        LAN | 192.168.178.0/24
            |
      .-----+------.
      | LAN-Switch |
      '-----+------'
            |
    ...-----+------... (Clients/Servers)



[micneu]

Kannst du mal genau erklären was dein Ziel sein soll?
Ich persönlich hätte das VPN über die Sense aufgebaut und über policy routing entsprechend das Gateway für bestimmte Geräte festgelegt (über das VPN)

Da ich nicht verstehe was genau dein Ziel ist, hoffe ich konnte dir damit helfen


Gesendet von iPhone mit Tapatalk Pro

[badsmoke]

in dem getrennten netz sind verschiedene geräte/vms die vpn verbindungen zu verschiedenen stellen aufbauen müssen.

ich hab z.b. externe geräte die sich alle auf ein vpn verbinden, einige vms sollen die externen geräte nachstellen, sich also auch auf diesen vpn server verbinden.

anderes Scenario: vm in einem extra vlan soll sich auf ein aws vpn netz verbinden um mit den vpc's zu interagieren. 

die vpn verbinden klappen wie schon geschrieben ohne probleme (ich kann mich ja noch per vms oberfläche drauf verbinden und test) aber die verbindung vom lan zu diesem geräten klappt nicht mehr


danke für deine Hilfe

[micneu]

ok, wie ich schon geschrieben habe (und trotzdem habe ich dein text nicht zu 100% verstanden)
sollte das auch so gehen wie ich geschrieben habe.
- du kannst (mit genug wissen) die vpn´s auf der sense einrichten und dann entsprechend regeln auf der sense für bestimmte ip´s anlegen die das vpn als default gateway nutzen.
- vorteil aus meiner sicht, du sparst resourcen, du hast alles an einer stelle
- um was für ein vpn handelt es sich denn genau?

[badsmoke]

danke aber der vpn client soll auf den entsprechenden geräten laufen.

Es geht dabei aber auch um testen der geräte die normalerweise als hardware im feld sind, es sollte also alles genauso wie auf den "echten" Geräten eingerichtet sein, auch das vpn.

[BusinessTux]

Wie sieht den ein

ip a

und ein

ip r

auf dem Linux mit dem VPN-Client aus?

Wohin zeigt das Default-Gateway der Linux-VM?
Setzt der VPN-Client nur statische Routen für die Remote-Netze hinter dem VPN oder wird der gesamte Traffic über das VPN-Interface geroutet?

[badsmoke]

die default routen sind gehen an die opnsense

das ist jetzt das bsp aws vpn Tunnel1/Tunnel2


ip r
```
default via 10.8.0.1 dev ens18 proto dhcp src 10.8.0.10 metric 100
10.8.0.0/24 dev ens18 proto kernel scope link src 10.8.0.10
10.8.0.1 dev ens18 proto dhcp scope link src 10.8.0.10 metric 100
169.254.127.80/30 dev Tunnel2 proto kernel scope link src 169.254.127.82
169.254.144.56/30 dev Tunnel1 proto kernel scope link src 169.254.144.58
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-351f2229a8bc proto kernel scope link src 172.18.0.1
192.168.0.0/16 dev Tunnel1 scope link metric 1000
192.168.0.0/16 dev Tunnel2 scope link metric 2000
```
ip a

```
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether fe:3f:82:51:67:78 brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.10/24 brd 10.8.0.255 scope global dynamic ens18
       valid_lft 6435sec preferred_lft 6435sec
    inet6 fe80::fc3f:82ff:fe51:6778/64 scope link
       valid_lft forever preferred_lft forever
3: ip_vti0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
5: br-351f2229a8bc: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:e9:61:f0:49 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-351f2229a8bc
       valid_lft forever preferred_lft forever
    inet6 fe80::42:e9ff:fe61:f049/64 scope link
       valid_lft forever preferred_lft forever
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:8b:10:b7:52 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
12: veth2f91958@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-351f2229a8bc state UP group default
    link/ether ce:ff:48:97:91:a4 brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet6 fe80::ccff:48ff:fe97:91a4/64 scope link
       valid_lft forever preferred_lft forever
14: vethb144f3c@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-351f2229a8bc state UP group default
    link/ether 2e:da:61:8a:30:37 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::2cda:61ff:fe8a:3037/64 scope link
       valid_lft forever preferred_lft forever
16: veth819d4fa@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-351f2229a8bc state UP group default
    link/ether 2a:b8:bc:1f:c5:f7 brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 fe80::28b8:bcff:fe1f:c5f7/64 scope link
       valid_lft forever preferred_lft forever
18: vethe92e64d@if17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-351f2229a8bc state UP group default
    link/ether 82:9f:83:85:85:ad brd ff:ff:ff:ff:ff:ff link-netnsid 3
    inet6 fe80::809f:83ff:fe85:85ad/64 scope link
       valid_lft forever preferred_lft forever
38: vethac92536@if37: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-351f2229a8bc state UP group default
    link/ether 62:5b:7e:2c:85:05 brd ff:ff:ff:ff:ff:ff link-netnsid 4
    inet6 fe80::605b:7eff:fe2c:8505/64 scope link
       valid_lft forever preferred_lft forever
110: vethd39bad2@if109: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-351f2229a8bc state UP group default
    link/ether 46:b0:39:a8:be:a6 brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::44b0:39ff:fea8:bea6/64 scope link
       valid_lft forever preferred_lft forever
112: vethbfef7a9@if111: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-351f2229a8bc state UP group default
    link/ether 32:ab:cd:a0:3f:12 brd ff:ff:ff:ff:ff:ff link-netnsid 6
    inet6 fe80::30ab:cdff:fea0:3f12/64 scope link
       valid_lft forever preferred_lft forever
113: Tunnel1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1419 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 10.8.0.10 peer 52.211.230.201
    inet 169.254.144.58 peer 169.254.144.57/30 scope global Tunnel1
       valid_lft forever preferred_lft forever
    inet6 fe80::5efe:a08:a/64 scope link
       valid_lft forever preferred_lft forever
114: Tunnel2@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1419 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 10.8.0.10 peer 52.212.108.147
    inet 169.254.127.82 peer 169.254.127.81/30 scope global Tunnel2
       valid_lft forever preferred_lft forever
    inet6 fe80::5efe:a08:a/64 scope link
       valid_lft forever preferred_lft forever

```

[BusinessTux]

Also vom Standard-Routing sieht das für mich in Ordnung aus.

Du hast vermutlich zwei VPN-Tunnel parallel mit unterschiedlicher Prio angebunden für die Ausfallsicherheit?

192.168.0.0/16 dev Tunnel1 scope link metric 1000
192.168.0.0/16 dev Tunnel2 scope link metric 2000

Oder warum ist bei beiden das gleiche Netz angegeben?

Allerdings sehe ich in den IP-Adressen nirgends VPN-Teilnehmer-IPs. Nur die zwei APIPA-IPs für die Tunnel:

113: Tunnel1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1419 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 10.8.0.10 peer 52.211.230.201
    inet 169.254.144.58 peer 169.254.144.57/30 scope global Tunnel1
       valid_lft forever preferred_lft forever
    inet6 fe80::5efe:a08:a/64 scope link
       valid_lft forever preferred_lft forever
114: Tunnel2@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1419 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 10.8.0.10 peer 52.212.108.147
    inet 169.254.127.82 peer 169.254.127.81/30 scope global Tunnel2
       valid_lft forever preferred_lft forever
    inet6 fe80::5efe:a08:a/64 scope link
       valid_lft forever preferred_lft forever

Wie sieht ein traceroute von der VM zu deinem LAN-Gerät bzw. umgekehrt aus, wenn der VPN verbunden ist? Auf beiden Seiten müssten die gleichen Hops auftauchen.

[badsmoke]

genau die beiden tunnel sind für die ausfallsicherheit, hätte noch ein anderes bsp bei dem nur ein tunnel genutzt wird.

gelöst:
danke für den hinweis ich hab zwar schon tausend mal in die routing tabellen geguckt aber erst jetzt ist mir aufgefallen

mein lan netzwerk (192.168.4.0/24) ist in in der vpn route mit drin 192.168.0.0/16.
hab jetzt ein extra route nur fürs lan netzwerk eingestellt, jetzt klappt es


danke für eure hilfe

[BusinessTux]

Gerne. Sehr schön.
Stimmt, die überlappende Subnetzmaske war mir auch nicht aufgefallen.