OPNsense OpenVPN szerver kapcsolat van, de adatforgalom nem megy.

Hálózatok egyéb

Helló!

OPNsense alatt próbálok OpenVPN szervert összehozni. Kapcsolatot OP3-on teszteltem OpenVPN klienssel, illetve a telefon 4G-t hotspotként megosztva Win10-en is. Mindkét esetben sikeres a csatlakozás, de sem a belső hálót nem tudom elérni, sem internetezni nem tudok.
Mindenből az aktuális legújabb verzió van.

Az egészet ez alapján csináltam végig:
https://www.kirkg.us/posts/building-an-openvpn-server-with-opnsense/

De mellé néztem még ezeket:
https://docs.opnsense.org/manual/how-tos/sslvpn_client.html
https://www.sparklabs.com/support/kb/article/setting-up-an-openvpn-server-with-opnsense-and-viscosity/
https://networkshinobi.wordpress.com/2017/05/29/opnsense-as-a-vpn-server/

Mivel a kapcsolat létrejön csak érdemi adatforgalmat nem tudok produkálni ezért a tűzfal szabályokra tippelek, hogy valami gond lehet. A fenti tutorialok alapján a varázsló ezeket létrehozza. Látszik is...Így viszont elakadtam, hogy mi lehet a gond.

Van valami ötletetek, hogy mi lehet a gond?

  • 1743 megtekintés

( KicsiBocs | 2018. 05. 09., sze – 09:21 )

Konfigurációs beállításokat (vpn, túzfal) és logokat láthatnánk esetleg?

Ma reggeli próbálkozásom Androidos kliens logban:
(Az érzékeny adatokat # karakterekkel takartam, vagy másra neveztem át, de látható)
Az otthonni belső hálóm 10.1.1.0/24... és most, hogy ezt leírtam nektek, leesett, hogy mit néztem be valószínűleg. Elírtam a belső háló címét, mert 10.0.0.0/24-es hálót adtam meg. (facepalm).

09:10:26.235 -- ----- OpenVPN Start -----

09:10:26.236 -- EVENT: CORE_THREAD_ACTIVE

09:10:26.260 -- Frame=512/2048/512 mssfix-ctrl=1250

09:10:26.272 -- UNUSED OPTIONS
0 [persist-tun]
1 [persist-key]
4 [tls-client]
7 [lport] [0]
8 [verify-x509-name] [server] [name]

09:10:26.273 -- EVENT: RESOLVE

09:10:26.288 -- Contacting ##### via UDP

09:10:26.288 -- EVENT: WAIT

09:10:26.291 -- Connecting to ###### [ via UDPv4

09:10:26.324 -- EVENT: CONNECTING

09:10:26.328 -- Tunnel Options:V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA256,keysize 256,tls-auth,key-method 2,tls-client

09:10:26.329 -- Creds: Username/Password

09:10:26.330 -- Peer Info:
IV_GUI_VER=OC30Android
IV_VER=3.2
IV_PLAT=android
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_LZO=1

09:10:26.377 -- VERIFY OK : depth=1
cert. version : 3
serial number : 00
issuer name : C=HU, ST=Pest, L=Budapest, O=O, emailAddress=admin@O.com, CN=N
subject name : C=HU, ST=Pest, L=Budapest, O=O, emailAddress=admin@O.com, CN=N
issued on : 2018-05-08 15:57:17
expires on : 2028-05-05 15:57:17
signed using : RSA with SHA-256
RSA key size : 2048 bits
basic constraints : CA=true

09:10:26.378 -- VERIFY OK : depth=0
cert. version : 3
serial number : 01
issuer name : C=HU, ST=Pest, L=Budapest, O=O, emailAddress=admin@O.com, CN=N
subject name : C=HU, ST=Pest, L=Budapest, O=O, emailAddress=admin@O.com, CN=server
issued on : 2018-05-08 15:57:17
expires on : 2028-05-05 15:57:17
signed using : RSA with SHA-256
RSA key size : 2048 bits
basic constraints : CA=false
cert. type : SSL Server
key usage : Digital Signature, Key Encipherment
ext key usage : TLS Web Server Authentication, ???

09:10:26.796 -- SSL Handshake: TLSv1.2/TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384

09:10:26.800 -- Session is ACTIVE

09:10:26.804 -- EVENT: GET_CONFIG

09:10:26.814 -- Sending PUSH_REQUEST to server...

09:10:26.843 -- OPTIONS:
0 [route] [10.0.0.0] [255.255.255.0]
1 [dhcp-option] [DNS] [10.1.1.12]
2 [route] [10.0.0.0] [255.255.255.0]
3 [route] [10.0.8.1]
4 [topology] [net30]
5 [ping] [10]
6 [ping-restart] [60]
7 [ifconfig] [10.0.8.6] [10.0.8.5]
8 [peer-id] [0]
9 [cipher] [AES-256-GCM]

09:10:26.844 -- PROTOCOL OPTIONS:
cipher: AES-256-GCM
digest: SHA256
compress: LZO
peer ID: 0

09:10:26.845 -- EVENT: ASSIGN_IP

09:10:26.866 -- Connected via tun

09:10:26.867 -- LZO-ASYM init swap=0 asym=0

09:10:26.872 -- EVENT: CONNECTED info='####@#####:#### (####) via /UDPv4 on tun/10.0.8.6/ gw=[10.0.8.5/]' trans=TO_CONNECTED

09:11:17.770 -- EVENT: DISCONNECTED trans=TO_DISCONNECTED

09:11:17.787 -- EVENT: CORE_THREAD_INACTIVE

09:11:17.788 -- Tunnel bytes per CPU second: 0

09:11:17.788 -- ----- OpenVPN Stop -----

Azokat kb fél óra múlva tudom csak betenni ide mert el kell mennem. De van még egy különös dolog. Most átírtam local network címeket mindenhol a jóra. Így már elérek bizonyos címeket és működik az internet is. Néhány címet elérek, néhányat nem. Pl 10.1.1.11 és 10.1.1.12 elérhető, de a 10.1.1.10 nem. A másik, hogy hívok egy what's my ip-t, akkor a Telekomos IP-m dobja, és nem az otthoni pulikus IP-m amire becsatlakoztam.

Két képet tudtam most lőni mobilról.

WAN
https://mega.nz/#!xyZGUJaB!D-WzCA3m8nH4bZ-gY0GQ026EOZhde2KhIsVadu6a0og

OPENVPN
https://mega.nz/#!RiY1SKob!YXthLvz51farLk2NfGEJzTk2EPaG2jruMRiuKDpnAV0

A NAT szabályoknál ennyi van: WAN -> LAN netwokrs, 127.0.0.0/8, 10.0.8.0/24

Még annyi, hogy a fenti logban bár nem látszik, de javítottam a helyi hálózat címet 10.1.1.0/24-re... Így már rálátok a helyi hálóra, bár az ESXI oldala nem jön be valamiért, a többi gép elérhető.
Viszont az IP-m kifelé továbbra is a mobilos 4g kapcsolat public ip-je, és nem az otthoni hálózat public IP-je.

Mármint melyikre? :) Összetett a problémám. Most elsőnek az a gond, hogy mobilon kapok a szolgáltatótól egy 37.x.x.x IP-t. Az otthoni wannak valami 172.x.x.x a publikus IP-je. Erre kapcsolódok VPN-en keresztül. Viszont ilyenkor továbbra is 37.x... kezdetű marad az IP-m. Ilyenkor nem a másikat kellene mutatnia?

Inkább először az kellene, hogy értelmesen megfogalmazza, mit szeretne. Aztán átgondolni, hogy az hogyan is működne, és beállítani a dolgokat a szerint. :-)

"Viszont az IP-m kifelé továbbra is a mobilos 4g kapcsolat public ip-je, és nem az otthoni hálózat public IP-je."

Én ebből azt feltételezem, hogy minden netes forgalámt a vpn-en akarná áttolni, de még mindig a mobilja ip-jét látja miden netes dolog. Nyilván az is kellene ( a masq/nat mellett), hogy belerouteolja a netes forgalmat a vpn-be. openvpn kapcsoló, default route rewrite vagy valami ilyesmi

Jogos. Tényleg nem fogalmazom meg értelmesen.

1. Igen, azt szeretném, hogy a VPN-en csatlakozott kliensek teljes hálózati forgalma a VPN-en át menjen.

2. A másik cél, hogy a VPN-re csatlakozott kliens a helyi gépeket is elérje, mintha ő is a helyi hálózat része lenne.

Csak egy kis rávezetésre van szükségem, hogy merre keresgéljek.

1. Erre írtam a gateway redirect vagy ilyemi opcióta szerver configba

2. Erre meg a push route körül nézelődj. a szerver a helyi háló ip tartományát a kliens csatlakozásánál áttolja a kliens routing táblájába ( bár ha az 1. miatt mindent áttolsz, akkor ez lehet, nem is kell már külön)

Meg valahogy a belső hálón lévő többi helyi gépnek, vagy azok gw-ének tudni kell, hogy a vpn kliensei felé menő válaszokat a vpn szervernek küldjék.

Persze, hogy kilásson a szerveren keresztül a vpn kliens, a szerveren az openvpn-től függetlenül meg kell oldani az ip forwardot és a natolást is kifelé

Amit írok, az sima openvpn-es megodás, nem tudom, hogy opnsense mennyivel másabb, de a logika ugyanez kell legyen.

( bennyh | 2018. 05. 09., sze – 09:23 )

OpenVPN-nél régebben a leggyakoribb hiba a route bejegyzések hiánya volt. Hiába jött létre kapcsolat, hacsak nem Layer2-es VPN, akkor marhára nem tudja a kliens, hogy merre az arra. Ez lehetett rosz konfig miatt, vagy jogosultsággondok miatt, utóbbi az újabb kliensekben le van kezelve, de attól még nem elvetendő a vizsgálata.
Magának a VPN tunnelnek a szerver oldalát tudod pingelni?
Route parancs jelzi, hogy merre van a távoli háló?

( trey | 2018. 05. 11., p – 08:14 )

tl;dr

pfSense / OPNsense-nél a bejövő VPN interfészre külön kell engedélyezni a forgalmat.

Firewall -> Rules -> Floating, LAN, WAN, <VPN típus>

--
trey @ gépház