Topic: Firewalling IPSEC Traffic

The content of this topic has been archived on 26 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Page 1 of 1

Post #1

KingJ

10 Sep 2014, 16:39

Hi,

I've successfully created a tunnel between my OpenWRT router and a pfSense Virtual Machine elsewhere on the internet. Phase 1 and 2 of the IPSEC tunnel are successfully negotiated and the tunnel is "up". However, i'm unable to ping across the tunnel and I suspect this may be due to firewall settings on the OpenWRT end - on the pfSense end all traffic is permitted to and from the tunnel. Indeed, if I initiate a ping from the pfSense side, I can see the ESP packets arriving on the OpenWRT's WAN interface.

Beyond permitting IPSEC traffic with the following rules in /etc/config/firewall i've made no firewalling changes;

config rule
        option src 'wan'
        option name 'IPSec ESP'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option src 'wan'
        option name 'IPSec IKE'
        option proto 'udp'
        option dest_port '500'
        option target 'ACCEPT'

config rule
        option src 'wan'
        option name 'IPSec NAT-T'
        option proto 'udp'
        option dest_port '4500'
        option target 'ACCEPT'

config rule
        option src 'wan'
        option name 'Auth Header'
        option proto 'ah'
        option target 'ACCEPT'

The firewall page on the OpenWRT wiki is a bit confusing. From what I can understand, it binds the IPSEC tunnel to a new VPN zone and policies are applied based on that - this matches my experience with commercial products. However, with a StrongSwan IPSEC connection, there is no interface I can bind to the VPN zone.

In short, i'm a little confused as to what firewall changes I need to make in order to permit the decrypted IPSEC traffic to be processed, rather than being dropped as seems to be the case now. The connection configuration on the OpenWRT side is below, and is near identical on the pfSense side aside from changing left/right etc. 10.0.0.0/24 is the subnet of my OpenWRT LAN.

conn pfsense
        left=1.1.1.1
        leftid=1.1.1.1
        leftsubnet=10.0.0.0/24
        right=2.2.2.2
        rightid=2.2.2.2
        rightsubnet=192.168.1.0/24
        authby=secret
        auto=start
        ike=3des-sha1-modp1024!
        esp = aes256-sha1!

If anyone could offer any insight, it would be appreciated. Thanks.

Edit: I should note that i'm running BarrierBreaker 14.07-rc3.

(Last edited by KingJ on 10 Sep 2014, 16:44)

Post #2

dorian

10 Sep 2014, 18:28

You probably just forgot to set up a route and/or NAT forwarding rules between the different subnets you are using. Unless you explicitly set the firewall to DROP packets, it will REJECT them by default. If they are being dropped as you say, they probably just can't be routed any further and time out.

Post #3

birnenschnitzel

10 Sep 2014, 18:57

The zone is not bound to an interface. It is simply a sum of all VPN target networks. The kernel IPsec rules (build by racoon or strongswan) will know how to handle the traffic.

Post #4

birnenschnitzel

10 Sep 2014, 19:01

And another tip. The VPN wiki explains a abstraction layer adapted to openwrt config design. With this data the additional start/stop scripts generate the firwall config and the strongswan/racoon Rules.

Post #5

KingJ

10 Sep 2014, 20:50

dorian wrote:

You probably just forgot to set up a route and/or NAT forwarding rules between the different subnets you are using. Unless you explicitly set the firewall to DROP packets, it will REJECT them by default. If they are being dropped as you say, they probably just can't be routed any further and time out.

After a fresh reboot, ip ro sh produces;

default via 62.3.84.21 dev pppoe-wan  proto static
10.0.0.0/24 dev br-lan  proto kernel  scope link  src 10.0.0.1
62.3.84.21 dev pppoe-wan  proto kernel  scope link  src MYIP
192.168.1.1 via 62.3.84.21 dev pppoe-wan  proto static

While the route is via the gateway rather than a tunnel etc, packets should still try to be routed and then intercepted by the kernel if my understanding is correct. It's interesting however, that the destination is a single IP rather than the 192.168.1.0/24 netblock specified in the IPSEC configuration as the right subnet.

birnenschnitzel wrote:

The zone is not bound to an interface. It is simply a sum of all VPN target networks. The kernel IPsec rules (build by racoon or strongswan) will know how to handle the traffic.

So in that case, the created VPN zone acts as a catch all for all VPN traffic (IPSEC, OpenVPN etc) and no further configuration is required in order to 'bind' VPN connections to the zone?

Thanks

(Last edited by KingJ on 10 Sep 2014, 20:50)

Post #6

KingJ

11 Sep 2014, 23:03

Still bashing my head against this. Interestingly, if I start a ping from OpenWRT's LAN interface to the LAN interface on the other side of the tunnel, a tcpdump on the OpenWRT WAN interface shows the ICMP packets going out over the WAN, i.e. towards the ISP's gateway, rather than being encapsulated in IPSEC.

I also notice that if I add a vpn zone via LuCI, I get a few warnings when reloading the firewall on the command line. Not sure if it's related, i'm clutching at straws here. I suspect that this is because the VPN zone has no interfaces assigned and hence no addressing information?

Warning: Unable to locate ipset utility, disabling ipset support
Warning: Section @zone[2] (vpn) has no device, network, subnet or extra options
Warning: Section @zone[2] (vpn) has no device, network, subnet or extra options
 * Clearing IPv4 filter table
 * Clearing IPv4 nat table
 * Clearing IPv4 mangle table
 * Clearing IPv4 raw table
 * Populating IPv4 filter table
   * Zone 'lan'
   * Zone 'wan'
   * Zone 'vpn'
Warning: fw3_ipt_rule_append(): Can't find target 'input_vpn_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'output_vpn_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'forwarding_vpn_rule'
   * Rule 'Allow-DHCP-Renew'
   * Rule 'Allow-Ping'
   * Rule 'IPSec ESP'
   * Rule 'IPSec IKE'
   * Rule 'IPSec NAT-T'
   * Rule 'Auth Header'
   * Forward 'lan' -> 'wan'
   * Forward 'vpn' -> 'lan'
   * Forward 'vpn' -> 'wan'
   * Forward 'lan' -> 'vpn'
   * Forward 'wan' -> 'vpn'
 * Populating IPv4 nat table
   * Zone 'lan'
   * Zone 'wan'
   * Zone 'vpn'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_vpn_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_vpn_rule'
 * Populating IPv4 mangle table
   * Zone 'lan'
   * Zone 'wan'
   * Zone 'vpn'
 * Populating IPv4 raw table
   * Zone 'lan'
   * Zone 'wan'
   * Zone 'vpn'
 * Clearing IPv6 filter table
 * Clearing IPv6 mangle table
 * Clearing IPv6 raw table
 * Populating IPv6 filter table
   * Zone 'lan'
   * Zone 'wan'
   * Zone 'vpn'
Warning: fw3_ipt_rule_append(): Can't find target 'input_vpn_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'output_vpn_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'forwarding_vpn_rule'
   * Rule 'Allow-DHCPv6'
   * Rule 'Allow-ICMPv6-Input'
   * Rule 'Allow-ICMPv6-Forward'
   * Rule 'IPSec ESP'
   * Rule 'IPSec IKE'
   * Rule 'IPSec NAT-T'
   * Rule 'Auth Header'
   * Forward 'lan' -> 'wan'
   * Forward 'vpn' -> 'lan'
   * Forward 'vpn' -> 'wan'
   * Forward 'lan' -> 'vpn'
   * Forward 'wan' -> 'vpn'
 * Populating IPv6 mangle table
   * Zone 'lan'
   * Zone 'wan'
   * Zone 'vpn'
 * Populating IPv6 raw table
   * Zone 'lan'
   * Zone 'wan'
   * Zone 'vpn'
 * Set tcp_ecn to off
 * Set tcp_syncookies to on
 * Set tcp_window_scaling to on

Thanks.

(Last edited by KingJ on 11 Sep 2014, 23:04)

Post #7

birnenschnitzel

15 Sep 2014, 17:05

The VPN concept I designed and wrote down in the wiki consists of four parts.

1) Define a standard openwrt /etc/config file that takes informations about the VPN infrastructure. E.g. foreing endpoints tunneled networks, credentials and so on. You can see it just like the usual strongswan/racoon configuration but in the openwrt style.

2) The part that is essential for the IKE damons is read out in the provided start scripts. These do nothing more than translating the new syntax into a daemon-specific standard syntax.

3) The config part with the network definitions must be mergend into the openwrt firewall. So we can route the traffic. The additional firewall script takes care of this.

4) with 1-3 in place we should have a working VPN solution but it will deny all traffic (to be safe and to emulate other firewalls). So we must add firewall rules between the newly created VPN zone and the existing zones manually in the web interface or the openwrt standard config files.

To sum it up: I tried to create a fully integrated solution that might be a little harder to understand and implement. But if everything works the rest is just the usual firewall-rule-clicking. Sorry for being out of this topic for the last two years but everyone is invited to take over maintenance.

Markus

Post #8

virusbcn

29 Sep 2014, 19:29

Kingj hello, i need have exactly the same, and the wiki openwrt confused me, please can you explain how to make ipsec in openwrt??? one example please ??

Thanks and best regards

Post #9

oferreiro

30 Sep 2014, 11:07

The easy way:

conn pfsense
left=1.1.1.1
leftid=1.1.1.1
leftsubnet=10.0.0.0/24
right=2.2.2.2
rightid=2.2.2.2
rightsubnet=192.168.1.0/24
authby=secret
auto=start
ike=3des-sha1-modp1024!
esp = aes256-sha1!
leftfirewall=yes

Another way:
You can define zones to your site (in site-to-site) or peer VPN connection.

config zone
option name 'vzone'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option subnet '192.168.1.0/24'
option family 'ipv4'

config forwarding
option dest 'lan'
option src 'vzone'
option family 'ipv4'

config forwarding
option dest 'vzone'
option src 'lan'
option family 'ipv4'

If you are using compress=yes allow ipencap.

config rule
option name 'ipsec-ipencap'
option target 'ACCEPT'
option src 'wan'
option proto 'ipencap'
option src_ip '2.2.2.2'
option extra '-m policy --dir in --pol ipsec --proto esp'
option family 'ipv4'

And prevent masquerade if your router have NATed interface (/etc/firewall.user)

iptables -t nat -A postrouting_rule -d 192.168.1.0/24 -j ACCEPT

(Last edited by oferreiro on 30 Sep 2014, 20:21)

Post #10

virusbcn

30 Sep 2014, 12:56

Thankyou obrigado Oferreiro, Thanks, I'm used to make connections site to site with several routers for years, but I'm lost with OpenWRT, maybe because I'm level linux "user",

What are the files I have to modify to create the VPN Ipsec ??

Post #11

oferreiro

30 Sep 2014, 15:42

Is possible use uci to configure ipsec connection. But I never used…
https://wiki.strongswan.org/projects/1/wiki/OpenWrtUCI

Normally I use pure strongswan configs.
You can copy it from test suites.
https://www.strongswan.org/testresults.html

Basically you needs edit:
- /etc/ipsec.conf
- /etc/ipsec.secrets
- strongswan.conf (In strongswan current version, strongswan.conf is modularized inside of /etc/strongswan.d)
- /etc/config/firewall
- /etc/firewall.user

Tips:
- Disable firewall on firsts tests (/etc/init.d/firewall stop). Sometimes we cannot ping right side of ESTABLISHED vpn connection (ipsec status) if firewall drop packets.
- enable left/rightfirewall on ipsec connection. You can inspect iptables rules (iptables-save) added by strongswan, to understand necessary rules to establish connection.
- (logread -f) is your friend.

(Last edited by oferreiro on 30 Sep 2014, 19:01)

Post #12

dDaYb

13 Feb 2015, 10:31

Hi!
I had working strongswan setup, but after upgrade to r44098 and strongswan 5.2.2 my old config doesn't work anymore, i.e. client connects, but routing / firewalling doesn't. I have

config rule
        option src 'wan'
        option name 'IPSec ESP'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option src 'wan'
        option name 'IPSec IKE'
        option proto 'udp'
        option dest_port '500'
        option target 'ACCEPT'

config rule
        option src 'wan'
        option name 'IPSec NAT-T'
        option proto 'udp'
        option dest_port '4500'
        option target 'ACCEPT'

config rule
        option src 'wan'
        option name 'Auth Header'
        option proto 'ah'
        option target 'ACCEPT'

in /etc/config/firewall and leftfirewall=yes in ipsec.conf

here is iptables-save -c

# Generated by iptables-save v1.4.21 on Fri Feb 13 12:27:45 2015
*nat
:PREROUTING ACCEPT [1737:162747]
:INPUT ACCEPT [325:25018]
:OUTPUT ACCEPT [281:22870]
:POSTROUTING ACCEPT [8:1204]
:delegate_postrouting - [0:0]
:delegate_prerouting - [0:0]
:postrouting_lan_rule - [0:0]
:postrouting_rule - [0:0]
:postrouting_vpn_rule - [0:0]
:postrouting_wan_rule - [0:0]
:prerouting_lan_rule - [0:0]
:prerouting_rule - [0:0]
:prerouting_vpn_rule - [0:0]
:prerouting_wan_rule - [0:0]
:zone_lan_postrouting - [0:0]
:zone_lan_prerouting - [0:0]
:zone_vpn_postrouting - [0:0]
:zone_vpn_prerouting - [0:0]
:zone_wan_postrouting - [0:0]
:zone_wan_prerouting - [0:0]
[1738:162799] -A PREROUTING -j delegate_prerouting
[0:0] -A POSTROUTING -m policy --dir out --pol ipsec -j ACCEPT
[1178:86559] -A POSTROUTING -j delegate_postrouting
[1178:86559] -A delegate_postrouting -m comment --comment "user chain for postrouting" -j postrouting_rule
[8:1204] -A delegate_postrouting -o br-lan -j zone_lan_postrouting
[1170:85355] -A delegate_postrouting -o eth1 -j zone_wan_postrouting
[1738:162799] -A delegate_prerouting -m comment --comment "user chain for prerouting" -j prerouting_rule
[1273:116029] -A delegate_prerouting -i br-lan -j zone_lan_prerouting
[465:46770] -A delegate_prerouting -i eth1 -j zone_wan_prerouting
[8:1204] -A zone_lan_postrouting -m comment --comment "user chain for postrouting" -j postrouting_lan_rule
[1273:116029] -A zone_lan_prerouting -m comment --comment "user chain for prerouting" -j prerouting_lan_rule
[0:0] -A zone_vpn_postrouting -m comment --comment "user chain for postrouting" -j postrouting_vpn_rule
[0:0] -A zone_vpn_prerouting -m comment --comment "user chain for prerouting" -j prerouting_vpn_rule
[1170:85355] -A zone_wan_postrouting -m comment --comment "user chain for postrouting" -j postrouting_wan_rule
[1170:85355] -A zone_wan_postrouting -j MASQUERADE
[465:46770] -A zone_wan_prerouting -m comment --comment "user chain for prerouting" -j prerouting_wan_rule
[1:52] -A zone_wan_prerouting -p tcp -m tcp --dport 22001 -m comment --comment "@redirect[0]" -j REDIRECT --to-ports 22
COMMIT
# Completed on Fri Feb 13 12:27:45 2015
# Generated by iptables-save v1.4.21 on Fri Feb 13 12:27:45 2015
*raw
:PREROUTING ACCEPT [229350:257883310]
:OUTPUT ACCEPT [1831:355106]
:delegate_notrack - [0:0]
:zone_vpn_notrack - [0:0]
[229350:257883310] -A PREROUTING -j delegate_notrack
[0:0] -A zone_vpn_notrack -j CT --notrack
COMMIT
# Completed on Fri Feb 13 12:27:45 2015
# Generated by iptables-save v1.4.21 on Fri Feb 13 12:27:45 2015
*mangle
:PREROUTING ACCEPT [229350:257883310]
:INPUT ACCEPT [4460:766953]
:FORWARD ACCEPT [221655:256204345]
:OUTPUT ACCEPT [1831:355106]
:POSTROUTING ACCEPT [223496:256560179]
:fwmark - [0:0]
:mssfix - [0:0]
[229350:257883310] -A PREROUTING -j fwmark
[221655:256204345] -A FORWARD -j mssfix
[922:53116] -A mssfix -o eth1 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "wan (mtu_fix)" -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# Completed on Fri Feb 13 12:27:45 2015
# Generated by iptables-save v1.4.21 on Fri Feb 13 12:27:45 2015
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:delegate_forward - [0:0]
:delegate_input - [0:0]
:delegate_output - [0:0]
:forwarding_lan_rule - [0:0]
:forwarding_rule - [0:0]
:forwarding_vpn_rule - [0:0]
:forwarding_wan_rule - [0:0]
:input_lan_rule - [0:0]
:input_rule - [0:0]
:input_vpn_rule - [0:0]
:input_wan_rule - [0:0]
:output_lan_rule - [0:0]
:output_rule - [0:0]
:output_vpn_rule - [0:0]
:output_wan_rule - [0:0]
:reject - [0:0]
:syn_flood - [0:0]
:zone_lan_dest_ACCEPT - [0:0]
:zone_lan_forward - [0:0]
:zone_lan_input - [0:0]
:zone_lan_output - [0:0]
:zone_lan_src_ACCEPT - [0:0]
:zone_vpn_dest_ACCEPT - [0:0]
:zone_vpn_dest_REJECT - [0:0]
:zone_vpn_forward - [0:0]
:zone_vpn_input - [0:0]
:zone_vpn_output - [0:0]
:zone_vpn_src_REJECT - [0:0]
:zone_wan_dest_ACCEPT - [0:0]
:zone_wan_dest_REJECT - [0:0]
:zone_wan_forward - [0:0]
:zone_wan_input - [0:0]
:zone_wan_output - [0:0]
:zone_wan_src_REJECT - [0:0]
[684:94180] -A INPUT -j delegate_input
[264:17237] -A FORWARD -s 192.168.4.1/32 -i eth1 -m policy --dir in --pol ipsec --reqid 5 --proto esp -j ACCEPT
[0:0] -A FORWARD -d 192.168.4.1/32 -o eth1 -m policy --dir out --pol ipsec --reqid 5 --proto esp -j ACCEPT
[1066:86430] -A FORWARD -j delegate_forward
[560:78321] -A OUTPUT -j delegate_output
[1066:86430] -A delegate_forward -m comment --comment "user chain for forwarding" -j forwarding_rule
[1:68] -A delegate_forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[1065:86362] -A delegate_forward -i br-lan -j zone_lan_forward
[0:0] -A delegate_forward -i eth1 -j zone_wan_forward
[0:0] -A delegate_forward -j reject
[0:0] -A delegate_input -i lo -j ACCEPT
[684:94180] -A delegate_input -m comment --comment "user chain for input" -j input_rule
[11:978] -A delegate_input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[9:448] -A delegate_input -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j syn_flood
[465:63226] -A delegate_input -i br-lan -j zone_lan_input
[208:29976] -A delegate_input -i eth1 -j zone_wan_input
[0:0] -A delegate_output -o lo -j ACCEPT
[560:78321] -A delegate_output -m comment --comment "user chain for output" -j output_rule
[205:31783] -A delegate_output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[31:6751] -A delegate_output -o br-lan -j zone_lan_output
[324:39787] -A delegate_output -o eth1 -j zone_wan_output
[5:2045] -A reject -p tcp -j REJECT --reject-with tcp-reset
[200:25983] -A reject -j REJECT --reject-with icmp-port-unreachable
[9:448] -A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 25/sec --limit-burst 50 -j RETURN
[0:0] -A syn_flood -j DROP
[31:6751] -A zone_lan_dest_ACCEPT -o br-lan -j ACCEPT
[1065:86362] -A zone_lan_forward -m comment --comment "user chain for forwarding" -j forwarding_lan_rule
[0:0] -A zone_lan_forward -d 178.248.234.14/32 -p tcp -m comment --comment "@rule[9]" -j zone_wan_dest_REJECT
[0:0] -A zone_lan_forward -d 178.248.234.14/32 -p udp -m comment --comment "@rule[9]" -j zone_wan_dest_REJECT
[1065:86362] -A zone_lan_forward -m comment --comment "forwarding lan -> wan" -j zone_wan_dest_ACCEPT
[0:0] -A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
[0:0] -A zone_lan_forward -j zone_lan_dest_ACCEPT
[465:63226] -A zone_lan_input -m comment --comment "user chain for input" -j input_lan_rule
[0:0] -A zone_lan_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
[465:63226] -A zone_lan_input -j zone_lan_src_ACCEPT
[31:6751] -A zone_lan_output -m comment --comment "user chain for output" -j output_lan_rule
[31:6751] -A zone_lan_output -j zone_lan_dest_ACCEPT
[465:63226] -A zone_lan_src_ACCEPT -i br-lan -j ACCEPT
[0:0] -A zone_vpn_forward -m comment --comment "user chain for forwarding" -j forwarding_vpn_rule
[0:0] -A zone_vpn_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
[0:0] -A zone_vpn_forward -j zone_vpn_dest_REJECT
[0:0] -A zone_vpn_input -m comment --comment "user chain for input" -j input_vpn_rule
[0:0] -A zone_vpn_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
[0:0] -A zone_vpn_input -j zone_vpn_src_REJECT
[0:0] -A zone_vpn_output -m comment --comment "user chain for output" -j output_vpn_rule
[0:0] -A zone_vpn_output -j zone_vpn_dest_ACCEPT
[1389:126149] -A zone_wan_dest_ACCEPT -o eth1 -j ACCEPT
[0:0] -A zone_wan_dest_REJECT -o eth1 -j reject
[0:0] -A zone_wan_forward -m comment --comment "user chain for forwarding" -j forwarding_wan_rule
[0:0] -A zone_wan_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
[0:0] -A zone_wan_forward -j zone_wan_dest_REJECT
[208:29976] -A zone_wan_input -m comment --comment "user chain for input" -j input_wan_rule
[0:0] -A zone_wan_input -p udp -m udp --dport 68 -m comment --comment Allow-DHCP-Renew -j ACCEPT
[0:0] -A zone_wan_input -p icmp -m icmp --icmp-type 8 -m comment --comment Allow-Ping -j ACCEPT
[0:0] -A zone_wan_input -p esp -m comment --comment "IPSec ESP" -j ACCEPT
[1:444] -A zone_wan_input -p udp -m udp --dport 500 -m comment --comment "IPSec IKE" -j ACCEPT
[1:1452] -A zone_wan_input -p udp -m udp --dport 4500 -m comment --comment "IPSec NAT-T" -j ACCEPT
[0:0] -A zone_wan_input -p ah -m comment --comment "Auth Header" -j ACCEPT
[1:52] -A zone_wan_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
[205:28028] -A zone_wan_input -j zone_wan_src_REJECT
[324:39787] -A zone_wan_output -m comment --comment "user chain for output" -j output_wan_rule
[324:39787] -A zone_wan_output -j zone_wan_dest_ACCEPT
[205:28028] -A zone_wan_src_REJECT -i eth1 -j reject
COMMIT
# Completed on Fri Feb 13 12:27:45 2015

192.168.4.1 is strongswan client, eth1 is wan interface (has 192.168.1.70). Everything looks fine to me but counters for output rule is empty - why?

I can ping lan interface of the router (192.168.3.1, where strongswan is installed) from strongswan client, but only 1 ping goes through to LAN client (192.168.3.200). Any ideas why? Thanks!

Post #13

ekx27

20 Oct 2016, 16:26

Hi,

I am also trying to filter the Strongswan VPN in Openwrt without success...
Is it a masquerading issue?

Best regards

Post #14

felipee07

20 Oct 2016, 17:30

all traffic must be filtered at FORWARD chain

The discussion might have continued from here.

Page 1 of 1