Tag Info

New answers tagged

1

You don't need a direct rule for this; firewalld already has a service definition for IPsec. firewall-cmd --zone=SemiTrusted --add-service=ipsec The definition permits all AH, ESP and UDP port 500 traffic. You'll need a second rule if either end has NAT and you need to add UDP port 4500: firewall-cmd --zone=SemiTrusted --add-port=4500/udp


1

I recently had this issue with only 1 of 2 SAs activating. I solved this by double checking sh run crypto map My ikev1 and ikev2 commands matched, but one side was misign crypto map WAN_map 1 set pfs After adding that command (substituting your actual crypto map name), and generating traffic from the initiator side, both SAs came up succesfully.


2

You didn't specify, but from your ifconfig -a excerpt we can assume you're running ipsec inside OpenVZ VE, not hardware node (HN). Just to be sure — did you check out theirs recommendation for that kind of set-up? OpenVZ's templates for VEs are really mind-blowing sometimes. I asked the devs why would one want to use 127/8 range IPs on non-loopback ...


0

Problem fixed. 1) I did not properly follow Michael's config directions. I also configured a rightsourceip and leftsourceip together, thereby causing both instances to believe they were both initiators. I ensured that one was an initiator and one was a requestor; this fixed the IKE problem. 2) I figured out that I also had to explicitly set the esp ...


1

From https://lists.openswan.org/pipermail/users/2010-June/018901.html When Openswan starts up, it looks like it picks the first IP Address on the br0 interface to announce what it’s picking. In case it picks wrong one of these days, how do I tell it definitively which IP Address on which interface? Or is this just an opening announcement ...


1

In VPC, the public IP address of an instance is never bound to the instance's stack, so you have to configure both the internal private address and the external public address. The invalid argument is presumably caused by trying to source traffic directly from the public IP address, which isn't known to your instance. left=10.10.10.10 # instance ...


0

The problem is the rngd-tools installed by the yum would not read the environment file /etc/sysconfig/rngd. open /usr/lib/systemd/system/rngd.service, add -r /dev/urandom to the ExecStart. ExecStart=/sbin/rngd -f -r /dev/urandom


0

Thanks to ecdsa, I've found several solutions of my problem. Use RADIUS Accounting without RADIUS Authentication. If eap-radius plugin is enabled with option accounting = yes, strongSwan will send RADIUS message to start accounting, even if eap-radius is not used in ipsec.conf file. In my case this RADIUS message looks like this: Acct-Status-Type = ...


0

It is my personal experience that this is possible but not recommended. In fact, I want to communicate to you that you should never ever use this configuration. Let me explain Layer 2 bridge mode is intended to not make any routing decisions, IPSEC VPNs require routing in order to be move the packets over the VPN. In fact, a host machine never knows what is ...


0

Turns out this is a bug in the version of OpenSwan I am using. I am using Amazon Linux AMI and the problem RPM is: openswan.x86_64 0:2.6.37-3.17.amzn1 I downgraded to openswan.x86_64 0:2.6.37-2.16.amzn1 and the issue disappeared. Apparently there are quite a few bugs in 3.17


0

RADIUS Accounting in the eap-radius plugin does not require XAuth authentication. It actually works with any kind of authentication, via RADIUS or not, as long as the client requests a virtual IP address (for IKEv2 even this requirement can be disabled). With some IKEv1 clients there are some issues in case of reauthentication, though (see issue #937 and ...



Top 50 recent answers are included