2

Just discovered that apple dropped pptp support in the newest MacOSes, so configured ikev2 ipsec access instead. Clients are happy, everything is simple and good except one thing - ipsec clients cannot access any services running on the same host the connects to. Of course it can be easily done using direct iptables config, but I use firehol for years and have a large config and no time to rewrite it back to iptables rules. And I have no idea how to specify ipsec access on the interface.

Details:

Suppose, I have eth1 wan interface for the internet access and internal eth0 interface for the lan and my firehol config looks like:

interface eth1 inet
    protection strong
    policy reject

    server ESP accept
    server AH accept
interface eth0 lan 
    policy accept
    client all accept
    server all accept
router inet2lan inface eth1 outface eth0
    client all accept
router lan2inet inface eth0 outface eth1
    route all accept
    masquerade

So far so good, I can connect to the server via ipsec and my packets nated to the lan well. But, the problem is, that I cannot connect to any services running directly on the server. As I understand, it happens because ikev2 is not real vpn but just a secure connection to the eth1 interface, so all policies for eth1 applied to any esp/ah connection. I checked it disabling all eth1 rules:

interface eth1 inet 
    policy accept
    client all accept
    server all accept

And found that really, in this case everything is working fine and all local services are accessible as well as lan.

So, my question is, how to separate configurations and to make something like:

interface eth1 inet server ESP AH
    policy accept
    client all accept
    server all accept
interface eth1 inet server not ESP AH
    protection strong
    policy reject

    server ESP accept
    server AH accept

It's just a sample, it's not working really, but maybe there's a way to configure such an access? Cannot find it anywhere, maybe I seek something wrong? As I understand, I just need to force firehol to perform something like:

iptables -I INPUT  --match policy --pol ipsec --dir in  --proto esp  -s 172.16.0.0/16 -j ACCEPT
iptables -I OUTPUT --match policy --pol ipsec --dir out  --proto esp  -d 172.16.0.0/16 -j ACCEPT

assuming remote host is in the 172.16/16. But have no idea how. Please help.

Thank you

BbIKTOP
  • 155
  • 8
  • Use internal IP addresses on your tunnel, or use IPsec in transport mode. – Michael Hampton Mar 07 '18 at 21:59
  • Sure I do use internal IP. But firehol blocks the access. What do you mean by "transport mode"? – BbIKTOP Mar 07 '18 at 22:03
  • Hmm. Well, I don't know if macOS will do transport mode anyway. And firehol is ancient and has hardly been maintained for years. So I'm not sure how or if it can do that. – Michael Hampton Mar 07 '18 at 23:33
  • Please tell me more about transport mode - how could it help? I don't understand. The problem is, that I need to allow these packets to pass my firewall, and I can't. And packets incapsulation woudn't change it anyway, isn't it? I edited the original post to be more specific. Why, last firehol version has been released Sep 17, 2017 so it's at least as ancient as linux itself )))) And firehol bugtracker is active and scripts work just fine including load balancing scripts that I use. Why do you think it's hardly maintained? Maybe I really need to think about switching back to plain iptables? – BbIKTOP Mar 07 '18 at 23:41
  • Transport mode doesn't set up a tunnel at all; it just encrypts any data between two endpoints, which continue to use their original IP addresses instead of tunnelled addresses. – Michael Hampton Mar 07 '18 at 23:44
  • Yes, I just don't understand and asked - how could it help in my case? – BbIKTOP Mar 07 '18 at 23:46

1 Answers1

0

Ok, I'll try to answer this as it has been years since I've used firehol, but here's how I used to create service exceptions:

# IP exception list (Madeup IP's of course, but you get the idea)
exceptIPs="10.4.1.12 172.16.0.12"

# Define request limit rate
inter_reqs="10/sec"
intr_reqs="20/sec"

# Define openvpn ports/service. Not defined by default.
server_openvpn_ports="udp/1194"
client_openvpn_ports="default"

# Define internet facing ports/services
intservices="openvpn ipsecnatt isakmp"

interface eth0 lan
  policy reject
  protection strong ${intr_reqs}

  server all accept
  server ident reject with tcp-reset

  client all accept

interface eth1 internet
  policy drop
  protection strong ${inter_reqs}

  server ${intservices} accept
  server ssh accept src ${exceptIPs}
  server ping accept src ${exceptIPs}
  server ident reject with tcp-reset

  client all accept

interface tun0 vpn
    # allow all incoming connections on the VPN
    server all accept

    # allow all outgoing connections on the tunnel device.
    client all accept

    router internet2vpn inface eth1 outface tun0
      # route freely to the VPN
      route all accept

    router vpn2internet inface tun0 outface eth1
      # use NAT masquerading from the VPN
      masquerade
      route "${intservices}" accept

    router vpn2lan inface tun0 outface eth0
      # Add routes to allow traffic from tun0 to internal network.
      route all accept

    router lan2vpn inface eth0 outface tun0
      # Add return route for VPN traffic
      route all accept

To address transport mode: Michael is referring to a specific form of host to host connection versus tunneling via a security gateway. I'm honestly having a little trouble finding much information on actually configuring for transport mode, but it is clearly stated that two modes exist for IPSEC in the RFC, Introduction paragraph:

https://datatracker.ietf.org/doc/html/rfc3884

Libreswan man page to follow. Look at the definition for the "type" parameter, in the conn section:

https://libreswan.org/man/ipsec.conf.5.html

As it stands your host is currently a router, and security gateway between the outside world and your internal LAN. As such, you're probably already running a tunneled IPSEC configuration, in contrast to a transport configuration. At least, it's likely that you are. You haven't posted anything about your IPSEC configuration so I don't know. That said, in libreswan the default is tunnel mode; You have to explicitly enable transport mode by defining the type parameter. Also for Libreswan, I can find no mention of transport mode in the configuration examples. That implies to me at least that this is not a particularly popular approach to configuring Libreswan for IPSEC.

Finally, Firehol is smart enough to know that you may sometimes wish to integrate iptables rules directly into the configuration. A quick look at the manpage should clarify this:

https://firehol.org/firehol-manual.html#firehol-iptables5

You will have to know which iptables queue you wish to dump your ruleset into though, which was in my experience quite complex via firehol.

I'm not sure if any of this will help you, but I thought I'd try and throw an answer out there.

I also agree with other commentors, that you should stop using firehol. Mostly due to speed, which is to say that firehol typically builds a ruleset of several 100, if not several 1000, rules for traffic. While the configuration files are pretty syntactically, it introduces significant slowness that you will notice if you switched back to normal iptables rules. I used to use this exact ruleset almost, and heard constant complaints about speed. This was over OpenVPN, which is slower than IPSEC anyway. My firewall is now around 20 lines, and connections are at least double the speed, even more so over IPSEC. While you may not have the time now, it would behoove you to eventually configure a test system and do some speed contrast tests.

Enoch Root
  • 166
  • 1
  • 7