Menu

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.

Show posts Menu

Messages - Bonkerton

#16
19.7 Legacy Series / Re: incorrect login
August 12, 2019, 06:24:23 AM
I just now tried the DVD image in a VM,
U: installer and PW: opnsense
worked fine.

Make sure your CAPS-lock is off,
and that you have the right keyboard layout
#17
19.7 Legacy Series / Re: ExpressVPN not working
August 11, 2019, 10:10:35 PM
I don't have ExpressVPN, but NordVPN and a few others, they all run fine on my OPNsense box

-When entering your data for the OpenVPN client, can you select the 'Disabled' checkbox right at the top. This should let you enter the data and save it without it taking effect. Maybe there''ll be a revealing message there.

- Does the log under VPN=>OpenVPN=>Log File show anything (after you re-open the browser window)?

- See if any of these posts help, maybe they do something differently
https://forum.opnsense.org/index.php?topic=4979
https://forum.opnsense.org/index.php?topic=13465.0

#18
19.7 Legacy Series / Re: ExpressVPN not working
August 10, 2019, 09:30:55 PM
Does it not give you any error message and just not save the client settings?

Does it stay on the settings page after hitting 'Save' or go back to the client overview?
#19
Check with a large download from a known fast site, to see which side is the culprit for slow speed.

Or a torrent, like a Linux distro ISO
#20

Addition:

Moved it back as my main system, WAN connected to my cable-modem.
Same story, WAN gets correct IP, but WAN Gateway IP that shows under [Interfaces:Overview:WAN] is stuck on old one (10.10.10.1 in this case)

Deleted WAN under Interfaces:Assignments and under System:Gateways:Single

Didn't reboot, and just reassigned WAN to re1-interface. Works again, until ISP changes gateway and I'll have to do it again...
#21
I had the problem that after the update to 19.7 all of a sudden one of my OpenVPN client interfaces was set as the the gateway instead of my WAN (which goes to a cable modem)
Described here
https://forum.opnsense.org/index.php?topic=13438.msg62208#msg62208

So I took my OPNsense router offline to debug. The setup for that is a router connected to a standalone router running OVPN which I use for my IOT devices, like this:
WAN <> OVPN-router <> Basic-Router <> OPNsense-FW for testing

The Basic-Router LAN-port was set to 172.20.20.1, and the OPNsense WAN correctly received an IP in that subnet and used 172.20.20.1 as the gateway for WAN.
After fixing the WAN/OVPN gateway assignment I had full internet again through the OPNsense box and thought I could put it back online.
Booted, internet didn't work. tried a lot of things, couldn't get it to work. Finally saw that the WAN DHCP gateway address was still stuck to the 'old' 172.20.20.1, while my WAN IP showed 24.119.xxx.4. The WAN gateway adress should have pointed to 24.119.xxx.1 - I was able to ping that address, but nothing else.

So I took it back to the test-setup described above.
1st screenshot attached: Old setup, gateway correct as 172.20.20.1 (most likely still stuck there from before)

Changed Basic-Router LAN to 172.21.21.1, rebooted that router and then rebooted OPNsense
2nd screenshot attached: new (correct) WAN IP, but gateway stuck at previous address (172.20.20.1)

Did a dhclient re1, no change.

3rd screenshot attached: tail of /var/db/dhclient.leases.re1

It shows the initial test setup with
-correct WAN IP & gateway
-changed&correct WAN IP & gateway (even though GUI still shows old/wrong gateway address)
-same WAN IP/GW after executing 'dhclient re1' - GUI still shows old/wrong gateway address

The I deleted the WAN IF & gateway in OPNsense GUI and rebooted.
Added the WAN IF back to re1 interface, had to do a DHCP 'Renew' in [Interfaces:Overview:WAN] and got the correct IP&GW addresses, and internet works.

Now I changed the Basic-Router LAN address (which should always be the OPNsense WAN gateway address) to 172.30.30.1
Rebooted the Basic-Router and then the OPNsense box and the IP & GW addresses had changed correctly.

Changed the Basic-Router LAN to 10.10.10.1
Rebooted the Basic-Router and then the OPNsense box and the IP & GW addresses had changed correctly.


TLDR:
If you lose internet connectivity down the road (because maybe your ISP changed your assigned dynamic WAN IP & gateway addresses) check if the correct gateway address is shown under [Interfaces:Overview:WAN] - it might be stuck at the old one.
If so, delete everything WAN under gateways and interfaces, reboot and re-create the WAN IF/GW
#22
I just had a similar problem after upgrading to 19.7, but with OVPN client

Had a few OVPN client connections set up before upgrade.
After the upgrade it picked the first active one (on port ovpnc2 - ovpnc1 is inactive) as the active gateway.

# ls /tmp/*defaultgw*   showed only  /tmp/ovpnc2_defaultgw

After reading this thread I checked the WAN gateway settings (under System: Gateways: Single) and its priority for GW-selection was 255, just like the OVPN gateway.


System: Settings: General Option "Allow default gateway switching" was and is disabled

When I select System: Settings: General: WAN  Option "Upstream Gateway" and save&apply,
once I go back into System: Settings: General: WAN the option is deselected again.

I dropped the value for GW-selection priority for WAN to 254, and now it's the active one.
(actually I dropped it to value of 10, but after save&apply it jumped to 254 by itself)
(Just played with that, setting it to a value below 129 + save&apply - it will show 254 when going back into the GW settings -- setting 129 stays put)

Also, when in System: Gateways: Single overview, clicking on the green arrow/triangle of an enabled gateway has no effect. When hovering over it there is a text-'popup' saying 'Disable', but nothing happens when clicking.

Going into the settings for a gateway and selecting option 'Disabled' + save&apply then shows that gateway as 'Pending' in the 'Status' column of System: Gateways: Single - but the green arrow/triangle is now grey presumably indicating that it is disabled.

#23
Here is discussion about the Tobii eye-tracking device
https://developer.tobii.com/community/forums/topic/network-sessions-with-rex-tcpip-driver/
where their SW seems to regularly try to connect to this address:port
"Yes, every second, the C:\Program Files (x86)\Tobii\Service\tobii.Service.exe tries hard to reach out to 172.28.195.1:4455 (which, of course, does not exist in most networks)."

You wouldn't happen to have something like this running?
#24
On recent Ubuntu version (the ones using systemd) the command to see Ubuntu's DNS setup is

systemd-resolve --status

Maybe there's some info in there.
#25
German - Deutsch / Re: VPN Client Probleme
March 11, 2019, 01:43:57 AM

hast du diese Link schon gesehen ?
https://forum.opnsense.org/index.php?topic=4979
https://torguard.net/knowledgebase.php?action=displayarticle&id=208

Was dir vielleicht fehlt sind die firewall rules. Von meinen Notizen, basierend auf den Links oben:
-------------------------------
Create Firewall Rules:
In the Browser-GUI navigate to Firewall > NAT > Outbound
     - Select 'Hybrid outbound NAT rule generation'
     - Click on [Save]
     - Click on [Apply changes]     (in the upper right corner of the page)

    - Click on [Add]     (in the upper right corner)
    - Interface: Select the VPN interface that we created before
    - Description (e.g. LAN traffic to VPN IF)
    - Click [Save]     (at the bottom of the page)
   
Now all your traffic should be routed through the VPN interface when the VPN connection is up.
But traffic will go back through your WAN interface when the VPN connection drops.
--------------

Um für das VLAN alle Gateways ausser VPN zu blockieren sollte das hier helfen:
https://www.infotechwerx.com/blog/Prevent-Any-Traffic-VPN-Hosts-Egressing-WAN
Funktioniert bei mir. Wobei ich keine VLANs benutze sondern mit der Floating Rule nur einzelne IPs auf den VPN-Gateway limitiere.
#26
Quote from: dp on March 04, 2019, 11:39:23 PM
Here is the upgrade output from the command line:

root@OPNsense:~ # opnsense-update -Vur 19.1
------
.+ opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/packages-19.1-OpenSSL-amd64.tar http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/packages-19.1-OpenSSL-amd64.tar
...+ [ -n -V ]

------
Did a reboot and still on version 18.

I re-did a V18 setup in a Virtualbox-VM and updated it from command line like you, then I diff'ed the command line output. The only differences were
- the '/var/cache/opnsense-update/85548' folder.
           I assume the folder-name/-number here is random

and this here:

.+ opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/85548/packages-19.1-OpenSSL-amd64.tar http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/packages-19.1-OpenSSL-amd64.tar
........................................................................+ [ -n -V ]

I have a lot more dots. Now I don't know if they signify the size of the file or just the time it took to download.

If I do a
wget http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/packages-19.1-OpenSSL-amd64.tar
at my Linux CLI the file that's downloaded is
'Length: 494723072 (472M)'
How big is yours ?

I rebooted the VM rebooted and it came back up with V19.1.1.
#27
So after working with this a bit longer

my actual question became more clear:

I have multiple OpenVPN clients set up. To run them concurrently I need multiple VPN-interfaces defined.
The only way to find out which network port (e.g. 'ovpnc7') is used by which OVPN client setup is
to go into the log and see on which port the client is trying to connect.

It becomes more of a hassle when - as is my case - I had set up some OVPN clients that I deleted later. So now, even though I have only 4 clients showing under 'VPN: OpenVPN: Clients' my network port count is up to ovpnc7. And the only way I see to match network port to client setup is to check the OVPN log.

Is that correct that there is no way to see/set this directly from the GUI ?
Any way to delete old/unused network ports ?
#28
This is from a Virtualbox environment (WAN DMZ'ed to internet, LAN on VBox internal network with a few clients. Initially I tried this on 18.7.10 and then updated to the 19.x RC to see if it's different. Which it wasn't.

I set up an OpenVPN client based on some HOW-To's and posts. That all worked well enough eventually. The VPN interface created created during that setup was on ovpnc1.

I then added a second client for the same VPN-provider but using a different server of theirs. All other settings were the same so I thought I'd re-use the already created interface.
That also worked, but when I look at the VPN log (or ifconfig) it shows that the second OVPN client setup is now using ovpnc2 as interface (or network port as it is called in the GUI).
Even though I never assigned this port. Also, ovpnc2 still shows as available for assignment in the GUI.

See attachments,
- VPN-clients shows the two client set-ups I have
- VPN-log shows that the second client is using ovpnc2 as port
- IF-assignments shows that ovpnc2 is still available for assignment

ifconfig (while second client is active):
ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet6 fe80::a00:27ff:fe82:f87d%ovpnc1 prefixlen 64 scopeid 0x7
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: tun openvpn
ovpnc2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet6 fe80::a00:27ff:fe82:f87d%ovpnc2 prefixlen 64 scopeid 0x8
inet 10.9.0.18 --> 10.9.0.17 netmask 0xffffffff
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: tun openvpn
Opened by PID 57326



I stumbled upon this when trying to add multiple clients for multiple VPN providers and the assignments didn't match between CLI/log and GUI.

So the problem/question is, why did ovpnc2 get taken into use even though the GUI still shows it as unassigned ?
Is this a known bug/feature ?
#29
German - Deutsch / Re: Realtime Network traffic
January 07, 2018, 02:04:51 AM

Alternativ pi-hole mit Raspberry oder in VM installieren
https://pi-hole.net/

und temporär (oder auf Dauer) als DNS server einstellen