Messages

16

German - Deutsch / Re: OPNSense soll Services übernehmen

« on: October 04, 2023, 11:41:12 am »

Hallo,
über DHCP den DNS Server von Opnsense bekannt geben. Außerdem Port Forward für alles, was nicht an deinen DNS Server gerichtet ist, auf deinen DNS-Server. Hierzu gibt es diverse Diskussionen in den Foren "hairpin".

17

Virtual private networks / Re: Route not working

« on: September 27, 2023, 10:02:36 pm »

It works. I have no idea why. Ping from synology to Opnsense started to work when I rebooted opnsense. So, something in Opnsense has blocked connections. I have no idea what. After the reboot, it appeared to work fine.

Remark: I assume it was Crowdsec that blocked the IP. Not sure.

18

Virtual private networks / Re: Route not working

« on: September 27, 2023, 09:03:54 pm »

I just realized that I cannot ping anything including the gateway from the synology system. Ping using ipv6 works fine, but not IPv4? When I change the static IP of the synology system, ping works. In case I change it back to 192.168.4.101, it stops working. Weird.

19

Virtual private networks / Re: Route not working

« on: September 27, 2023, 08:18:39 pm »

Yes, ssh and tcpdump are available. From Opnsense Terminal I can SSH into the synology (ssh 192.168.4.101). tcpdump on opnsense on the 192.168.4.0 interface provides a lot of traffic. I can also do SSH into the synology from other subnets (192.168.2.0)

20

Virtual private networks / Re: Route not working

« on: September 27, 2023, 08:10:00 pm »

How can I check that? The target system .4.101 is a synology disk station running nextcloud

21

Virtual private networks / [Solved] Route not working

« on: September 27, 2023, 07:08:16 pm »

I have a weird issue. I push a route 192.168.4.0/24 to the client. At the client, route shows the following correctly:

Code: [Select]

root@237:/etc/openvpn# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway.xx. 0.0.0.0         UG    0      0        0 eth0
xx.xx.232.0     0.0.0.0         255.255.248.0   U     0      0        0 eth0
192.168.4.0     192.168.25.1    255.255.255.0   UG    0      0        0 tun0
192.168.25.0    0.0.0.0         255.255.255.0   U     0      0        0 tun0

However, I cannot access any machine on 192.168.4.xx. Sporadically, after reboot of firewall or the client side, a connection is possible. Further, in case I add further routes to other subnets of the firewall, these work immediately.

In the firewall log I see the connection incoming. It seems to be routed to the correct interface. But then no response.

Does anyone have an idea how the track the problem and find a solution?

22

General Discussion / Re: Wrong prefix delegation size

« on: September 27, 2023, 04:46:24 pm »

I configured both firewalls to independently acquire their prefixes, no Carp for IPv6. The main firewall just uses RA with higher priority than the backup firewall. This will provide me the IPv6 via the main firewall in case of the main firewall = Master. And in case the main firewall fails, IPv6 will automatically use the backup. It is not seamless I assume, but it should work.

23

General Discussion / Re: Wrong prefix delegation size

« on: September 27, 2023, 02:53:10 pm »

Thanks for the answer Franco! The ISP somehow ignores indeed the hint. I have now set the prefix length in the WAN settings to the prefix length acutally provided to me (which was currently 58). Not a nice solution, but it works for the moment.

Regarding CARP IPv6 I have to explain the background: I cannot configure the Ipv6 HA setup as illustrated in the manual (https://docs.opnsense.org/manual/how-tos/carp.html). This is because I have only a quasi static IPv6 which may change from time to time. My idea was to use WAN track interface and have the LAN on firewall 1 assigned a different v6 subnet than LAN on firewall 2. In the above example of the manual: Firewall 1 LAN 2001:db8:1234:1::1/64, Firewall 2 LAN 2001:db8:1234:2::1/64. Nevertheless, a common virtual CARP address is broadcasted fe80::2 for both LANs.

I assume  that the routing is done via the fe80::2, which is either pointing to firewall 1 in the master mode or to firewall 2 in the backup mode. If yes, this would make use of the less powerful firewall 2 only in exemptional cases (firewall 1 is newer, faster, has more RAM etc).

Is that understanding correct?

24

General Discussion / Wrong prefix delegation size

« on: September 27, 2023, 09:58:39 am »

Hello,
until last night IPv6 worked fine. After playing a bit around with CARP and IPv6, I reconfigured everything to the previous setup but now the WAN interface shows the wrong prefix delegation size (which should be 57, but it indicates a 58). Further, non of the interfaces using track interface is showing an IPv6 any more. My first question would be how to force the WAN interface to use the Prefix delegation size actually set in the [WAN] Interfaces setting?

My second more general question is the following: since my ISP rarely changes the prefix, I cannot set a CARP for virtual WAN which corresponds to a real IPv6 GUA but I would have to use someting like fe80::1 or fd00::1. Is that possible? If yes, is there any additional routing required on the side of the ISP router or any NAT in opnsense or whatsoever?

Thanks!!

25

Virtual private networks / Re: OpenVPN dhcp-option DNS not working

« on: September 25, 2023, 05:29:38 pm »

YES!

26

Virtual private networks / Re: OpenVPN dhcp-option DNS not working

« on: September 25, 2023, 03:40:27 pm »

The client should be able to use it (I assume the client is so outdated). Irrespective make sure you indicate the correct DNS server in the server settings. In my case since I'm using adguard I additionally have a port forwarding that forwards any DNS requests originating from OpenVPN and not directed to the indicated DNS Server to the correct (internal) DNS server.

27

Virtual private networks / Re: OpenVPN Instances

« on: September 22, 2023, 09:54:42 pm »

You connect to your dyndns address from WAN, correct? Since openvpn 1194 binds to any interface and thus to WAN, you will always have a connection from outside to port 1194? Even in case the IP changes, dynamic DNS will point you to the correct new IP. I don't see why this should effect Openvpn?

28

High availability / Re: HA and OpenVPN

« on: September 22, 2023, 02:32:24 pm »

Hmmm, under virtualIP - status the Openvpn Carp is reported as "Disabled". Not sure what the problem is? I tried everything that came to my mind. Whenever I choose a VPN interface for CARP, the result is that the status is "DISABLED" and the virtual IP is NOT assigned to the respective VPN interface.

(I create per Server a respective VPN Interface to which I try to assign the CARP address). What am I doing wrong?

Update : I also tried to use the field "Bind address" and input the Virtual Carp IP of WAN. The result is

Code: [Select]

TCP/UDP: Socket bind failed on local address [AF_INET6]fe80::1:1:1196: Can't assign requested address (errno=49)

29

High availability / Re: HA and OpenVPN

« on: September 22, 2023, 02:06:07 pm »

yes, sure. But this is already ensured due to all other Interfaces also exposed to the WAN.

30

High availability / Re: HA and OpenVPN

« on: September 22, 2023, 01:01:23 pm »

Thank you. What do you mean by

Then use the CARP address of the cluster as the OpenVPN endpoint for your clients.

The clients connect from the internet to the Firewall which has the respective Openvpn port open?