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

Topics - Kofl

#1
18.7 Legacy Series / [Solved] nping functionality
November 07, 2018, 04:13:31 PM
Hi,

is there any tool for opnsense equal to e.g. nping to forge the source ip for testing via icmp?

Thanks,
Thomas
#2
Hi,

when we go to /status_graph.php, Report Traffic and select IPSec, the top list is empty, although traffic is active.
Anyone experiencing the same issue?

Settings the Interface to e.g. LAN works fine, and the top list is shown.

Thx
#3
18.7 Legacy Series / Direct edit of ipsec.conf possible?
November 05, 2018, 12:50:34 PM
Hi,

we have for one VPN connection many subnets to route and via GUI its hard to add them.

Is it possible to edit directly the ipsec.conf or where is OPNsense storing its own configuration for strongswan?

Thanks
#4
Hi,

we are running our OPNsense on Hyper-V for month, and every x weeks, the GUI is no longer working and access via ssh is broken (seems the ssdh daemon is down).

Firewall routing is still fine, also openswan is working as expected.

So far we also cant login via console, it hangs after entering "root" for the login.

The console output only shows:

hvvss0: Unknown opt from host: 4

Did anyone experience a similar behavior?

OPNsense version = 18.7.5

Thanks,
Thomas
#5
Hi,

we setup OPNsense (latest version of today) with OpenVPN, which works fine so far.

OpenVPN -> Servers -> Server Certificate, we use the internal OPNsense for "Server Certificate".

Error on the windows client:


Jun 09 14:46:41: OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed


Client: openvpn-install-2.4.6-I602.exe, latest version from openvpn.net. Same issue with Viscosity as openvpn-client.

Solution: On client export use "Inline Configuration", "other" and NOT Archive.

Hopefully also for someone else.

Best





#6
Hello,

we are struggling with the setup of IPSec NAT although I did it based on the documentation. So far the IPSec tunnel works fine:

Source Network: 192.168.16.0/24
Destination Network: 10.17.0.0/16

Now we also have to tunnel the source network 10.51.18.0/24 over that VPN connection.

Manual SPD entries: 10.51.18.0/24 for phase 2

Firewall: NAT: One-to-One
External network: 192.168.16.0/24
Source: 10.51.18.0/24
Destination: 10.17.0.0/16

But the packets are not translated, tcpdump shows:

IP 10.51.18.90 > 10.17.3.2: ICMP echo request

Any hint on what we are missing?

Thanks,
Thomas
#7
Hello,

we had massive issues to get the VPN OPNsense <-> Cisco ASA working. This small article is hopefully helpful for someone else and saving massive headaches :)

OPNsense 18.1 sends by default not only the configured Traffic Selectors for IPSEC Phase2 to the Cisco ASA, but also the public IP addresses, which the ASA will refuse.

So IPSEC initialization only works from the ASA site, but not from the OPNSense site, except you up the tunnel by hand on OPNSense. If its initiated by traffic from the OPNSense site, the phase2 negotiation fails. Strange, but true.

Workaround:
/usr/local/etc/strongswan.conf


charon {
..
ignore_acquire_ts=yes
..
}


QuoteIf this is disabled the traffic selectors from the kernel's acquire events, which are derived from the triggering packet, are prepended to the traffic selectors from the configuration for IKEv2 connection. By enabling this, such specific traffic selectors will be ignored and only the ones in the config will be sent. This always happens for IKEv1 connections as the protocol only supports one set of traffic selectors per CHILD_SA.

The issue so far seems to be caused by FreeBSD, as other *unix are not affected:
https://wiki.strongswan.org/issues/1313

Thanks for the attention,
Thomas