Messages

16

German - Deutsch / Re: Firewall Log Normal View

« on: May 10, 2018, 03:44:40 pm »

Schließe mich an, irgendeine Filtermöglichkeit wäre notwendig

Ld

17

18.1 Legacy Series / Re: IPSec OPNsense <-> Cisco ASA not working (solution inside)

« on: May 07, 2018, 09:59:22 am »

Awesome, thanks

18

18.1 Legacy Series / Re: 18.1.7 (installed)

« on: May 06, 2018, 06:26:16 pm »

Thanks

19

18.1 Legacy Series / Re: IPSec NAT not working

« on: May 05, 2018, 02:36:19 pm »

Solved,

https://doc.pfsense.org/index.php/NAT_with_IPsec_Phase_2_Networks:

In a packet capture, the actual address will be shown on outbound traffic, not the translated address. This does not indicate any problem.

As soon as the admin of the other site allowed the traffic, everything went fine:

Code: [Select]

14:31:26.676550 (authentic,confidential): SPI 0xbdb31e3b: IP 10.51.18.90 > 10.17.3.2: ICMP echo request, id 1, seq 873, length 40
14:31:26.712898 (authentic,confidential): SPI 0xcb1e1127: IP 10.17.3.2 > 192.168.16.90: ICMP echo reply, id 1, seq 873, length 40

Thanks @mimugmail

20

18.1 Legacy Series / Re: IPSec NAT not working

« on: May 05, 2018, 01:59:38 pm »

rules.debug also looks fine:

Code: [Select]

binat on enc0 from 10.51.18.0/24 to 10.17.0.0/24 -> 192.168.16.0/24

Makes also no difference if I try NAT instead of BINAT

Code: [Select]

nat on enc0 from 10.51.18.0/24 to 10.17.0.0/24 -> 192.168.16.0/24


21

18.1 Legacy Series / Re: 18.1.5 IPv6 bogons invalid after update

« on: May 05, 2018, 01:43:16 pm »

Thanks, also solved the issue for me:

Firewall --> Settings --> Advanced --> Firewall Maximum Table Entries: 500'000

Code: [Select]

pfctl -t bogonsv6 -T flush
rm /usr/local/etc/bogonsv6
/usr/local/etc/rc.update_bogons


22

18.1 Legacy Series / Re: IPSec NAT not working

« on: May 05, 2018, 01:26:02 pm »

Its IP

23

18.1 Legacy Series / Re: IPSec NAT not working

« on: May 05, 2018, 01:17:43 pm »

Thanks,

unfortunately same result:

Destination: 10.17.0.0/24

> ping 10.17.0.2

10.51.18.90 > 10.17.0.2: ICMP echo request

24

18.1 Legacy Series / [SOLVED] IPSec NAT not working

« on: May 05, 2018, 11:33:43 am »

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

25

18.1 Legacy Series / Re: Letsencrypt new certificate dropdown list Validation Method empty

« on: May 04, 2018, 11:33:44 am »

Just for info, did a fresh installation yesterday with the current version and there it worked flawless.

26

18.1 Legacy Series / Re: Windows IPsec VPN authetication with Active Directory and FreeRADIUS

« on: April 28, 2018, 07:22:49 pm »

Maybe it would be a solution to use Windows Radius, which uses AD to authenticate?
http://thesolving.com/server-room/configure-radius-server-windows-authenticate-cisco-vpn-users/

and then configure OPNSense to use that radius server:
https://wiki.opnsense.org/manual/how-tos/user-radius.html

27

18.1 Legacy Series / IPSec OPNsense <-> Cisco ASA not working (solution inside)

« on: April 27, 2018, 08:20:48 pm »

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

Code: [Select]

charon {
..
ignore_acquire_ts=yes
..
}


If 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