1
General Discussion / Re: NAT reflection not working
« on: April 08, 2023, 02:57:41 pm »
Thank you, I spent hours to find this setting. It should be mentioned in the documentation.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
2
20.7 Legacy Series / Re: Unbound - restarted when interface wakes up? (is delay and BlackLists)
« on: December 07, 2020, 12:30:05 pm »
Just wanted to let you know that I had an old, invalid entry under System - Gateways - Single. Since I removed it, the problem is gone.
3
20.7 Legacy Series / Re: kernel: pflog0: promiscuous mode dis-/enabled MORE OFTEN THAN every 15 min
« on: December 06, 2020, 11:34:44 am »
Today I removed the cause for this entry:
2020-12-05T14:21:53 configd.py[932] [f7dbdaa5-97f5-45c2-a8c7-d84d1e622cec] updating dyndns WG_MULLVAD_GW
WG_MULLVAD_GW didn't even exist anymore, so far I don't didn't have a single issue in > 5 h. Yesterday the issue was getting worse the later it got. Also with my PC shut down and nothing accessing the web front end. Let's see if it was the dpinger thing. So far, it looks good.
2020-12-05T14:21:53 configd.py[932] [f7dbdaa5-97f5-45c2-a8c7-d84d1e622cec] updating dyndns WG_MULLVAD_GW
WG_MULLVAD_GW didn't even exist anymore, so far I don't didn't have a single issue in > 5 h. Yesterday the issue was getting worse the later it got. Also with my PC shut down and nothing accessing the web front end. Let's see if it was the dpinger thing. So far, it looks good.
4
20.7 Legacy Series / Re: kernel: pflog0: promiscuous mode dis-/enabled MORE OFTEN THAN every 15 min
« on: December 05, 2020, 08:30:24 am »
I don't have the log anymore.
After I shut down my workstation the behavior stopped and hasn't returned since I turned my workstation back on.
/Edit: I can confirm that when the config interface isn't opened inside a browser, the issue doesn't appear, so far.
/Edit2
It returned
After I shut down my workstation the behavior stopped and hasn't returned since I turned my workstation back on.
/Edit: I can confirm that when the config interface isn't opened inside a browser, the issue doesn't appear, so far.
Code: [Select]
Dec 4 22:45:09 OPNsense kernel: pflog0: promiscuous mode disabled
Dec 4 22:45:09 OPNsense kernel: pflog0: promiscuous mode enabled
Dec 4 22:46:00 OPNsense kernel: pflog0: promiscuous mode disabled
Dec 4 22:46:00 OPNsense kernel: pflog0: promiscuous mode enabled
Dec 4 22:47:08 OPNsense kernel: pflog0: promiscuous mode disabled
Dec 4 22:47:08 OPNsense kernel: pflog0: promiscuous mode enabled
Dec 4 22:57:09 OPNsense kernel: pflog0: promiscuous mode disabled
Dec 4 22:57:09 OPNsense kernel: pflog0: promiscuous mode enabled
Dec 4 22:57:22 OPNsense kernel: pflog0: promiscuous mode disabled
Dec 4 22:57:22 OPNsense kernel: pflog0: promiscuous mode enabled
Dec 5 10:00:18 OPNsense kernel: pflog0: promiscuous mode disabled
Dec 5 10:00:18 OPNsense kernel: pflog0: promiscuous mode enabled
Dec 5 10:01:17 OPNsense kernel: pflog0: promiscuous mode disabled
Dec 5 10:01:17 OPNsense kernel: pflog0: promiscuous mode enabled
Dec 5 10:04:03 OPNsense kernel: pflog0: promiscuous mode disabled
Dec 5 10:04:03 OPNsense kernel: pflog0: promiscuous mode enabled
Dec 5 10:04:04 OPNsense kernel: pflog0: promiscuous mode disabled
Dec 5 10:04:04 OPNsense kernel: pflog0: promiscuous mode enabled
Dec 5 10:04:06 OPNsense kernel: pflog0: promiscuous mode disabled
Dec 5 10:04:06 OPNsense kernel: pflog0: promiscuous mode enabled[/code
10:10 I closed the tab, it is now 13:00/Edit2
It returned
Code: [Select]
2020-12-05T14:23:30 configd.py[932] [3e58f1c1-c342-4232-8a86-2eb1a10d2276] Show log
2020-12-05T14:23:28 configd.py[932] message d851624f-959f-433c-914d-4f5a9f98e48a [filter.refresh_aliases] returned {"status": "ok"}
2020-12-05T14:23:27 configd.py[932] [bad6ac7a-e482-4fc9-9bd3-92712d30124d] updating dyndns WG_MULLVAD_GW
2020-12-05T14:23:27 configd.py[932] [d851624f-959f-433c-914d-4f5a9f98e48a] refresh url table aliases
2020-12-05T14:23:27 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
2020-12-05T14:23:27 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_tables.conf
2020-12-05T14:23:27 configd.py[932] generate template container OPNsense/Filter
2020-12-05T14:23:26 configd.py[932] [9c1e580f-0f4c-417d-b3b1-c6e91e18aa48] generate template OPNsense/Filter
2020-12-05T14:23:26 configd.py[932] [46cc3743-03f3-41bc-ad71-d1e56308cf07] Reloading filter
2020-12-05T14:23:17 configd.py[932] [548e5ab7-3531-4626-b02c-b59e542cdc88] Show log
2020-12-05T14:23:16 configd.py[932] message bb9b39c7-5de1-48d1-ad69-cf8ec06dc41f [filter.refresh_aliases] returned {"status": "ok"}
2020-12-05T14:23:15 configd.py[932] [9b70e446-811e-453f-a8f6-9080b7970cc6] updating dyndns WG_MULLVAD_GW
2020-12-05T14:23:15 configd.py[932] [bb9b39c7-5de1-48d1-ad69-cf8ec06dc41f] refresh url table aliases
2020-12-05T14:23:15 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
2020-12-05T14:23:15 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_tables.conf
2020-12-05T14:23:15 configd.py[932] generate template container OPNsense/Filter
2020-12-05T14:23:15 configd.py[932] [09e0421f-0234-4a64-83c3-ea7b724a1b16] generate template OPNsense/Filter
2020-12-05T14:23:14 configd.py[932] [64538364-3f9d-4e7f-abd7-bd53c40f5c8e] Reloading filter
2020-12-05T14:23:11 configd.py[932] [cdfbf8f1-c37e-4925-a20e-888dcddf2e8a] Reading system temperature values
2020-12-05T14:23:11 configd.py[932] [b15ff43a-9e15-4ff1-af19-85b6cd11bea6] request pfctl byte/packet counters
2020-12-05T14:23:05 configd.py[932] [675b97f2-a13c-43a6-a1d8-7f15d5419810] Reading system temperature values
2020-12-05T14:23:04 configd.py[932] [ad933e3b-2087-4ccf-9273-e8eae74b2dca] request pfctl byte/packet counters
2020-12-05T14:21:54 configd.py[932] message e24066b6-3639-45a2-ae3e-87a7e115aa94 [filter.refresh_aliases] returned {"status": "ok"}
2020-12-05T14:21:53 configd.py[932] [f7dbdaa5-97f5-45c2-a8c7-d84d1e622cec] updating dyndns WG_MULLVAD_GW
2020-12-05T14:21:53 configd.py[932] [e24066b6-3639-45a2-ae3e-87a7e115aa94] refresh url table aliases
2020-12-05T14:21:53 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
2020-12-05T14:21:53 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_tables.conf
2020-12-05T14:21:53 configd.py[932] generate template container OPNsense/Filter
2020-12-05T14:21:53 configd.py[932] [262dbfda-0787-488d-9bfd-711df39c16c7] generate template OPNsense/Filter
2020-12-05T14:21:52 configd.py[932] [5382f17d-9631-4214-abbd-4b3f188e12d4] Reloading filter
2020-12-05T14:21:38 configd.py[932] message 1528e4cf-deab-437e-ab7e-642befea130b [filter.refresh_aliases] returned {"status": "ok"}
2020-12-05T14:21:37 configd.py[932] [3c92a705-a7d3-4f1c-97dd-c42c2c611c00] updating dyndns WG_MULLVAD_GW
2020-12-05T14:21:37 configd.py[932] [1528e4cf-deab-437e-ab7e-642befea130b] refresh url table aliases
2020-12-05T14:21:37 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
2020-12-05T14:21:37 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_tables.conf
2020-12-05T14:21:37 configd.py[932] generate template container OPNsense/Filter
2020-12-05T14:21:37 configd.py[932] [69a767ac-fa99-4434-8212-14eab983bf7c] generate template OPNsense/Filter
2020-12-05T14:21:36 configd.py[932] [bb52bea8-6036-49e6-805f-12fdf1fda36c] Reloading filter
2020-12-05T14:20:37 configd.py[932] message 1ea589b6-aac6-405b-8d91-52415f8965da [filter.refresh_aliases] returned {"status": "ok"}
2020-12-05T14:20:36 configd.py[932] [8604bf9d-9a8e-41f6-8bc9-d473172fdeb3] updating dyndns WG_MULLVAD_GW
2020-12-05T14:20:36 configd.py[932] [1ea589b6-aac6-405b-8d91-52415f8965da] refresh url table aliases
2020-12-05T14:20:36 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
2020-12-05T14:20:36 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_tables.conf
2020-12-05T14:20:35 configd.py[932] generate template container OPNsense/Filter
2020-12-05T14:20:35 configd.py[932] [a0d8911e-60b7-48a8-8e96-7747d332d130] generate template OPNsense/Filter
2020-12-05T14:20:35 configd.py[932] [a8e35c13-1faf-4bf5-ae0b-911bb2610e19] Reloading filter
2020-12-05T14:20:12 configd.py[932] message dcb11523-e364-4623-bfab-4c9a81d68409 [filter.refresh_aliases] returned {"status": "ok"}
2020-12-05T14:20:11 configd.py[932] [93e2b77b-759f-46bb-b5cb-80be5c387212] updating dyndns WG_MULLVAD_GW
2020-12-05T14:20:11 configd.py[932] [dcb11523-e364-4623-bfab-4c9a81d68409] refresh url table aliases
2020-12-05T14:20:11 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
2020-12-05T14:20:11 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_tables.conf
2020-12-05T14:20:10 configd.py[932] generate template container OPNsense/Filter
2020-12-05T14:20:10 configd.py[932] [5514d7ad-a5c0-4f1a-b65c-f0b7989a26b2] generate template OPNsense/Filter
2020-12-05T14:20:10 configd.py[932] [a9624d75-cc33-472a-9f45-628ed007f408] Reloading filterCode: [Select]
2020-12-05T14:23:27 kernel pflog0: promiscuous mode enabled
2020-12-05T14:23:27 kernel pflog0: promiscuous mode disabled
2020-12-05T14:23:15 kernel pflog0: promiscuous mode enabled
2020-12-05T14:23:15 kernel pflog0: promiscuous mode disabled
2020-12-05T14:22:20 sudo[38393] *** : TTY=pts/1 ; PWD=/home/*** ; USER=root ; COMMAND=/usr/local/sbin/opnsense-shell
2020-12-05T14:22:20 sudo[38393] *** : TTY=pts/1 ; PWD=/home/*** ; USER=root ; COMMAND=/usr/local/sbin/opnsense-shell
2020-12-05T14:22:20 opnsense[18336]
2020-12-05T14:22:20 opnsense[18336] user *** authenticated successfully for sudo [using OPNsense\Auth\Services\System + OPNsense\Auth\Local]
2020-12-05T14:22:16 sshd[49163] Accepted keyboard-interactive/pam for *** from 192.168.10.3 port 40538 ssh2
2020-12-05T14:22:16 sshd[49163] Postponed keyboard-interactive/pam for *** from 192.168.10.3 port 40538 ssh2 [preauth]
2020-12-05T14:22:16 opnsense[90495]
2020-12-05T14:22:16 opnsense[90495] user *** authenticated successfully for sshd [using OPNsense\Auth\Services\System + OPNsense\Auth\Local]
2020-12-05T14:22:13 sshd[49163] Postponed keyboard-interactive for *** from 192.168.10.3 port 40538 ssh2 [preauth]
2020-12-05T14:22:13 sshd[49163] error: PAM: Authentication error for *** from 192.168.10.3
2020-12-05T14:22:13 sshd[49163] error: PAM: Authentication error for *** from 192.168.10.3
2020-12-05T14:22:13 opnsense[52151]
2020-12-05T14:22:13 opnsense[52151] user *** could not authenticate for sshd. [using OPNsense\Auth\Services\System + OPNsense\Auth\Local]
2020-12-05T14:21:53 kernel pflog0: promiscuous mode enabled
2020-12-05T14:21:53 kernel pflog0: promiscuous mode disabled
2020-12-05T14:21:37 kernel pflog0: promiscuous mode enabled
2020-12-05T14:21:37 kernel pflog0: promiscuous mode disabled
2020-12-05T14:20:36 kernel pflog0: promiscuous mode enabled
2020-12-05T14:20:36 kernel pflog0: promiscuous mode disabled
2020-12-05T14:20:11 kernel pflog0: promiscuous mode enabled
2020-12-05T14:20:11 kernel pflog0: promiscuous mode disabled
5
20.7 Legacy Series / Re: kernel: pflog0: promiscuous mode dis-/enabled MORE OFTEN THAN every 15 min
« on: December 04, 2020, 09:24:35 pm »
Having the same problem. Connections drop every now and then, somtimes multiple times per minute, sometimes it takes some more minutes.
OPNsense 20.7.5-amd64 // up to date packages
https://pastebin.com/K7GPEhN0
OPNsense 20.7.5-amd64 // up to date packages
Code: [Select]
General:
2020-12-04T21:08:25 kernel pflog0: promiscuous mode enabled
2020-12-04T21:08:25 kernel pflog0: promiscuous mode disabled
Backend:
2020-12-04T21:08:26 configd.py[932] message 2249bace-f1ab-4951-ab10-34003008d972 [filter.refresh_aliases] returned {"status": "ok"}
2020-12-04T21:08:25 configd.py[932] [ac4a9a66-1ff7-429d-8401-f85ae1b45c5b] updating dyndns <snip>
2020-12-04T21:08:25 configd.py[932] [2249bace-f1ab-4951-ab10-34003008d972] refresh url table aliases
2020-12-04T21:08:25 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
2020-12-04T21:08:25 configd.py[932] OPNsense/Filter generated //usr/local/etc/filter_tables.conf
2020-12-04T21:08:25 configd.py[932] generate template container OPNsense/Filter
2020-12-04T21:08:25 configd.py[932] [0b58104c-3461-4f29-9185-6be7ce99fd93] generate template OPNsense/Filter
2020-12-04T21:08:24 configd.py[932] [d28eca11-c501-4f0a-8385-295bd7efbf54] Reloading filterhttps://pastebin.com/K7GPEhN0
6
Virtual private networks / Re: Wireguard & Mullvad - I'm lost.....
« on: October 28, 2020, 08:13:42 am »
FWIW, I changed to openvpn for other reasons.¹ I hope wireguard gets proper support one day.
¹ https://github.com/opnsense/core/issues/4389
¹ https://github.com/opnsense/core/issues/4389
7
General Discussion / Re: WireGuard & Port Forwarding
« on: October 02, 2020, 09:03:47 pm »
FYI, I ran into the same issue and opened a bug report on github, if anyone wants to chime in
https://github.com/opnsense/core/issues/4389
https://github.com/opnsense/core/issues/4389
9
German - Deutsch / Re: Probleme beim Port Forwarding LAN<->OPNsense<->Wireguard
« on: October 02, 2020, 04:30:09 pm »10
German - Deutsch / Re: Probleme beim Port Forwarding LAN<->OPNsense<->Wireguard
« on: October 02, 2020, 03:12:49 pm »
Gibt's dazu schon einen bugreport? Ich habe es jahrelang mit openwrt so gemacht.
11
German - Deutsch / Probleme beim Port Forwarding LAN<->OPNsense<->Wireguard
« on: October 02, 2020, 02:36:42 pm »
Hallo Community,
ich habe das gleiche Problem schon einmal hier beschrieben: https://forum.opnsense.org/index.php?topic=19386.0 aber hier scheint mehr los zu sein. Wenn das Problem behoben ist, markiere ich beide als SOLVED.
Ich fasse mich so kurz wie möglich:
Ein PC (LAN, 192.168.20.101) ist mit OPNsense firewall Verbunden (igb1, 192.168.20.1). OPNsense hat zwei WAN Schnittstellen, DSL und Wireguard (wg0, WAN IP 185.209.196.159). 192.168.20.0/24 benutzt wg0 als gateway (NAT). Ich habe Port 11526 von wg0 auf 192.168.20.101:11526 weitergeleitet. Wenn ich mit versuche aus dem Internet auf meine wireguard WAN IP auf Port 11526 zu verbinden (ncat -p 23023 185.209.196.159 11526), kann ich folgendes auf igb1 beobachten(tcpdump -i igb1 | grep ".23023"):
Es werden also die Paket an 192.168.20.101 weitergeleitet und beantwortet. So weit, so gut.
Wenn ich das gleich auf wg0 mache, dann werden die SYN ACK Pakete nicht über wg0 rausgeschickt.
Meine limitierten Kenntnise lassen mich vermuten, dass irgendwas an der Firewall nicht stimmt. Verbindungsaufbau über NAT funktioniert von innen, aber nicht von außen? Die SYN ACK Pakete bleiben in der Firewall hängen.
Im Anhang noch ein paar Screenshots.
Jede Hilfe ist sehr willkommen.
Vielen Dank im Voraus!
Anhang:
https://i.imgur.com/x9hBagG.png
https://i.imgur.com/dJs9l38.png
https://i.imgur.com/Ylx9J3L.png
ich habe das gleiche Problem schon einmal hier beschrieben: https://forum.opnsense.org/index.php?topic=19386.0 aber hier scheint mehr los zu sein. Wenn das Problem behoben ist, markiere ich beide als SOLVED.
Ich fasse mich so kurz wie möglich:
Ein PC (LAN, 192.168.20.101) ist mit OPNsense firewall Verbunden (igb1, 192.168.20.1). OPNsense hat zwei WAN Schnittstellen, DSL und Wireguard (wg0, WAN IP 185.209.196.159). 192.168.20.0/24 benutzt wg0 als gateway (NAT). Ich habe Port 11526 von wg0 auf 192.168.20.101:11526 weitergeleitet. Wenn ich mit versuche aus dem Internet auf meine wireguard WAN IP auf Port 11526 zu verbinden (ncat -p 23023 185.209.196.159 11526), kann ich folgendes auf igb1 beobachten(tcpdump -i igb1 | grep ".23023"):
Code: [Select]
19:28:57.774733 IP xxx.de.23023 > 192.168.20.101.11526: Flags [S], seq 1802740233, win 64240, options [mss 1380,sackOK,TS val 79282081 ecr 0,nop,wscale 7], length 0
19:28:57.775498 IP 192.168.20.101.11526 > xxx.de.23023: Flags [S.], seq 1252543376, ack 1802740234, win 65160, options [mss 1460,sackOK,TS val 1133438719 ecr 79282081,nop,wscale 7], length 0
19:28:58.776502 IP xxx.de.23023 > 192.168.20.101.11526: Flags [S], seq 1802740233, win 64240, options [mss 1380,sackOK,TS val 79283084 ecr 0,nop,wscale 7], length 0
19:28:58.777248 IP 192.168.20.101.11526 > xxx.de.23023: Flags [S.], seq 1252543376, ack 1802740234, win 65160, options [mss 1460,sackOK,TS val 1133439721 ecr 79282081,nop,wscale 7], length 0
19:28:59.779374 IP 192.168.20.101.11526 > xxx.de.23023: Flags [S.], seq 1252543376, ack 1802740234, win 65160, options [mss 1460,sackOK,TS val 1133440723 ecr 79282081,nop,wscale 7], length 0
19:29:00.792129 IP xxx.de.23023 > 192.168.20.101.11526: Flags [S], seq 1802740233, win 64240, options [mss 1380,sackOK,TS val 79285100 ecr 0,nop,wscale 7], length 0
19:29:00.792870 IP 192.168.20.101.11526 > xxx.de.23023: Flags [S.], seq 1252543376, ack 1802740234, win 65160, options [mss 1460,sackOK,TS val 1133441737 ecr 79282081,nop,wscale 7], length 0
19:29:02.979382 IP 192.168.20.101.11526 > xxx.de.23023: Flags [S.], seq 1252543376, ack 1802740234, win 65160, options [mss 1460,sackOK,TS val 1133443923 ecr 79282081,nop,wscale 7], length 0
19:29:04.888799 IP xxx.de.23023 > 192.168.20.101.11526: Flags [S], seq 1802740233, win 64240, options [mss 1380,sackOK,TS val 79289196 ecr 0,nop,wscale 7], length 0
19:29:04.888967 IP 192.168.20.101.11526 > xxx.de.23023: Flags [S.], seq 1252543376, ack 1802740234, win 65160, options [mss 1460,sackOK,TS val 1133445833 ecr 79282081,nop,wscale 7], length 0
19:29:08.952726 IP 192.168.20.101.11526 > xxx.de.23023: Flags [S.], seq 1252543376, ack 1802740234, win 65160, options [mss 1460,sackOK,TS val 1133449897 ecr 79282081,nop,wscale 7], length 00Es werden also die Paket an 192.168.20.101 weitergeleitet und beantwortet. So weit, so gut.
Wenn ich das gleich auf wg0 mache, dann werden die SYN ACK Pakete nicht über wg0 rausgeschickt.
Code: [Select]
19:34:19.395412 IP xxx.de.23023 > 10.65.68.45.11526: Flags [S], seq 2533116111, win 64240, options [mss 1380,sackOK,TS val 79603694 ecr 0,nop,wscale 7], length 0
19:34:20.408152 IP xxx.de.23023 > 10.65.68.45.11526: Flags [S], seq 2533116111, win 64240, options [mss 1380,sackOK,TS val 79604707 ecr 0,nop,wscale 7], length 0
19:34:22.424482 IP xxx.de.23023 > 10.65.68.45.11526: Flags [S], seq 2533116111, win 64240, options [mss 1380,sackOK,TS val 79606723 ecr 0,nop,wscale 7], length 0
19:34:26.682679 IP xxx.de.23023 > 10.65.68.45.11526: Flags [S], seq 2533116111, win 64240, options [mss 1380,sackOK,TS val 79610980 ecr 0,nop,wscale 7], length 0Meine limitierten Kenntnise lassen mich vermuten, dass irgendwas an der Firewall nicht stimmt. Verbindungsaufbau über NAT funktioniert von innen, aber nicht von außen? Die SYN ACK Pakete bleiben in der Firewall hängen.
Im Anhang noch ein paar Screenshots.
Jede Hilfe ist sehr willkommen.
Vielen Dank im Voraus!
Anhang:
https://i.imgur.com/x9hBagG.png
https://i.imgur.com/dJs9l38.png
https://i.imgur.com/Ylx9J3L.png
12
German - Deutsch / Re: Wireguad Regel hat keinen Einfluss
« on: October 02, 2020, 01:25:54 pm »Code: [Select]IPv4 * 10.10.10.15 * 192.168.1.5 * * * wireguard
Ich sehe nicht viel, aber ich sehe hier keine Regel, die den Verkehr aus dem 10.10.10.0/24 (Wireguard Netz?) Netz in das 192.168.1.0/24 (LAN?) Netz regelt.
Hast du mal unter Firewall: {wireguard interface} hinzugefügt:
Action: REJECT
Interface: {wireguard interface}
Destination: {LAN interface}
?
13
German - Deutsch / Re: Wireguad Regel hat keinen Einfluss
« on: October 02, 2020, 11:05:39 am »
Kannst du deine Regeln posten, am Besten floating, WireGuard und falls vorhanden die fuer das wireguard interface.
14
Virtual private networks / Re: OpenVPN - Access to local network
« on: October 01, 2020, 10:18:52 pm »
Connection works means you can ping from both sites?
Please show your:
OpenVPN Server settings
Server Firewall Settings
Client OpenVPN settings
Client Firewall Settings
Please show your:
OpenVPN Server settings
Server Firewall Settings
Client OpenVPN settings
Client Firewall Settings
15
Virtual private networks / Re: Wireguard - Problems with LAN access
« on: October 01, 2020, 10:11:45 pm »
Hi,
I'm just a hobby user, so keep that in mind when you read my answer
Do you have CGNAT, or what is the deal with your VPS?
1.) That's not really a problem of opnsense I am afraid. What you could do is NAT between the two networks, but that should be avoided if possible. Putting both on the same network (bridging) is also possible, but you probably get some unwanted overhead traffic through your wireguard interface.
2.) I don't understand that point. What name resolution doesn't work? You said DNS requests are answered by PiHole, but not resolved?
So far I don't see anything specific to wireguard.
I'm just a hobby user, so keep that in mind when you read my answer
Do you have CGNAT, or what is the deal with your VPS?
1.) That's not really a problem of opnsense I am afraid. What you could do is NAT between the two networks, but that should be avoided if possible. Putting both on the same network (bridging) is also possible, but you probably get some unwanted overhead traffic through your wireguard interface.
2.) I don't understand that point. What name resolution doesn't work? You said DNS requests are answered by PiHole, but not resolved?
So far I don't see anything specific to wireguard.
Pages: [1] 2