Messages

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

Ld

Awesome, thanks

Thanks

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 Expand


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

rules.debug also looks fine:

Code Select Expand


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 Expand


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


Thanks, also solved the issue for me:

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

Code Select Expand


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


Its IP

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

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

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

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

[Workaround]

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 Expand


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