|
IPv6 Firewall Issue on OpenWrt
![[de]](/s/countries/de.gif) Shadow Hawkins on Wednesday, 05 December 2012 11:23:21
Hello,
I'm attempting to setup an IPv6 tunnel on my OpenWrt Backfire router.
The router is able to successfully ping6 google.com. Only the devices in
my LAN are not able to pin6 the outside world. They are able to ping6 the router
and have successfully received an ipv6 address via radvd. If I turn of the routers
firewall, the devices in the lan can successfully ping6 the outside world, but only for a few minutes. Could somebody please take a look at my network/firewall configuration and tell me what's wrong?
Thank you very much!
ifconfig output: https://gist.github.com/08ac90294e5453629fa2
/etc/config/network: https://gist.github.com/ed6ee138a98fea1d3e55
/etc/config/firewall: https://gist.github.com/601f9eb55d3ca5a5dda5
IPv6 Firewall Issue on OpenWrt
Only the devices in my LAN are not able to pin6 the outside world.
Which could be:
- misconfigured prefix
- forwarding not enabled
- forwarding blocked (ip6tables)
but only for a few minutes.
You did not do connection tracking I hope?
Another, very annoying problem, could be that you have broken multicast on your network....
br-lan Link encap:Ethernet HWaddr D8:5D:4C:F6:30:EE inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 > inet6 addr: 2001:6f8:900:8e85::1/64 Scope:Global
That looks good, thus the misconfigured prefix it is not.
There is not tunnel interface configured on the node though, thus where do the packet go?
/etc/config/firewall is a bit useless to read as other rules can have sneaked in.
Please do a 'ip6tables -v --list -n', optionally also for some alternate tables like the raw one.
Definitely check your forwarding setting with 'sysctl -a |grep forwarding'
Note also that using the [ code ] blocks indicated on the right when posting one can easily included output of data.
IPv6 Firewall Issue on OpenWrt
Shadow Hawkins on Wednesday, 05 December 2012 19:28:41
Hi Robert,
/etc/config/network doesn't contain an interface definition for use with AICCU!
In my case this looks like:
config interface 'wan6'
option ifname 'sixxs'
option proto 'static'
option ip6addr '<tunnel-prefix>::2/64'
option auto '1'
option send_rs '0'
Hint: Don't use 'sixxs.0' for ifname option, in my configuration that didn't work, but 'sixxs' did.
Make sure, that /etc/aiccu.conf contains the following option:
ipv6_interface sixxs
So AICCU knows that it shall use wan6 interface.
Within /etc/config/firewall only the zone 'lan' and 'wan6' are relevant for IPv6. zone 'wan' is IPv4 only, so all defined rules for zone 'wan' with option family ipv6 don't make sence.
Here are the relevant parts of /etc/config/firewall:
...
config zone
option name lan
option network 'lan'
....
config zone
option name wan
option network 'wan'
....
config zone
option name wan6
option network 'wan6'
option input DROP
option output ACCEPT
option forward DROP
option family ipv6
config forwarding
option src lan
option dest wan6
config rule
option name RHO
option src wan6
option proto all
option extra '-m rt --rt-type 0'
option family ipv6
option target DROP
config rule
option name RHO2
option src wan6
option dest lan
option proto all
option extra '-m rt --rt-type 0'
option family ipv6
option target DROP
config rule
option name 'Allow-Ping-ipv6'
option src wan6
option proto icmp
option output ACCEPT
option forward REJECT
list icmp_type echo-request
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
list icmp_type router-solicitation
list icmp_type neighbour-solicitation
list icmp_type echo-reply
option limit 1000/sec
option family ipv6
option target ACCEPT
PacketTracer
IPv6 Firewall Issue on OpenWrt
/etc/config/network doesn't contain an interface definition for use with AICCU!
It does not need one (depending on how you start AICCU), and your definition is defining a STATIC tunnel, which thus means that you do not need to use AICCU.
Also, I do not know what/how OpenWRT sets up tunnels, but typically one will want to setup a default gateway.
Make sure, that /etc/aiccu.conf contains the following option:
So you are going to let something (OpenWRT /etc/config/network) set up a static interface, and then let AICCU use that; that is really asking for problems; AICCU cannot fix broken setups below it.
Thus if that works, it is pure magic...
I guess the only reasoning for having something in /etc/config/network is so that the custom firewall toolset that OpenWRT has knows which interface is which, thus that wan6 maps to the sixxs interface, but in that case adding other configuration options there is odd to say the least.
But in short: you do not need any details in /etc/config/network (or if debian/ubuntu in /etc/network/interfaces) when you are going to use AICCU anyway...
IPv6 Firewall Issue on OpenWrt
Shadow Hawkins on Wednesday, 05 December 2012 20:19:58
I used the configuration from your Wiki, see Firewalling (using OpenWrt firewall2 configuration)
I'm operating OpenWRT on a small TP-Link box that sits within my LAN behind an IPv4 NAT router which routes proto 41 packets to my TP-Link box. As the public IPv4 address of my NAT router changes once per day I need heartbeat and hence AICCU running. The TP-Link box has one ethernet interface only which is used both for native IPv6 LAN packets and the tunnel:
Here is my config:
root@OpenWrt:~# ifconfig
br-lan Link encap:Ethernet HWaddr F8:D1:11:C0:37:CE
inet addr:192.168.178.30 Bcast:192.168.178.31 Mask:255.255.255.224
inet6 addr: fe80::fad1:11ff:fec0:37ce/64 Scope:Link
inet6 addr: 2001:4dd0:XXXX::1/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:643192 errors:0 dropped:64925 overruns:0 frame:0
TX packets:508515 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:463661217 (442.1 MiB) TX bytes:451618175 (430.6 MiB)
eth0 Link encap:Ethernet HWaddr F8:D1:11:C0:37:CE
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:779018 errors:0 dropped:0 overruns:0 frame:0
TX packets:508515 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:515664131 (491.7 MiB) TX bytes:451618175 (430.6 MiB)
Interrupt:4
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
sixxs Link encap:IPv6-in-IPv4
inet6 addr: fe80::c0a8:b21e/64 Scope:Link
inet6 addr: 2001:4dd0:<my-tunnel>::2/64 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1472 Metric:1
RX packets:315170 errors:0 dropped:0 overruns:0 frame:0
TX packets:184303 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:423431654 (403.8 MiB) TX bytes:19405523 (18.5 MiB)
root@OpenWrt:~# ip -6 route show
2001:4dd0:XXXX::/64 dev br-lan proto kernel metric 256
2001:4dd0:<my-tunnel>::/64 via :: dev sixxs proto kernel metric 256
fe80::/64 dev br-lan proto kernel metric 256
fe80::/64 via :: dev sixxs proto kernel metric 256
default via 2001:4dd0:<my-tunnel>::1 dev sixxs metric 1024
It works like a charm! (The high drop rate for br-lan stems from the NDAS protocol sent by a network harddisk directly as ethernet broadcasts, the ethernet type isn't understood/supported by the TP-Link box and hence these packets get dropped)
Andreas
IPv6 Firewall Issue on OpenWrt
I used the configuration from your Wiki
Almost all Wiki content is user-provided and not verified. Hence also the difference between the FAQ and the Wiki.
As such, it might be what is in the Wiki is not always 100% correct or verified or or or...
It works like a charm!
Yes, but likely because of a bit of luck, as I can only assume that the OpenWRT config also sets up the tunnel interface partially, and that will definitely break if that tunnel is then suddenly supposed to be an AYIYA interface....
IPv6 Firewall Issue on OpenWrt
Shadow Hawkins on Wednesday, 05 December 2012 21:19:13as I can only assume that the OpenWRT config also sets up the tunnel interface partially, and that will definitely break if that tunnel is then suddenly supposed to be an AYIYA interface....
Why should a change of tunnel mode happen suddenly? It is a very consciously happening event that costs 15 ISK ;-)
Before configuring my NAT box to forward proto 41 packets to my OpenWRT device, I operated the tunnel in AYIYA mode using exactly the same configuration (I changed to heartbeat mode due to the lower overhead/higher MTU value). As far as I remember I just had to restart AICCU to make the new tunnel mode become operative.
IPv6 Firewall Issue on OpenWrt
Why should a change of tunnel mode happen suddenly?
Not suddenly, but there are lots and lots of people who cut & paste, and this setup does most likely not work when the tunnel type is AYIYA....
It is a very consciously happening event that costs 15 ISK ;-)
Actually, this might be changing sometime, this as there is no real cost anymore on the PoP to change tunnel type due to sixxsd v4. Or even more elaborated, AICCU is intended to do graceful lowering of tunnel type, starting with attempting to do a heartbeat tunnel and falling back to AYIYA where needed.
As far as I remember I just had to restart AICCU to make the new tunnel mode become operative
I am really wondering what effect the statements in /etc/config/network have. Do they actually configure a tunnel/interface or does it do nothing at all, as it expects the kernel to supply the interface?
IPv6 Firewall Issue on OpenWrt
Shadow Hawkins on Wednesday, 05 December 2012 22:08:49I am really wondering what effect the statements in /etc/config/network have. Do they actually configure a tunnel/interface or does it do nothing at all, as it expects the kernel to supply the interface?
Unfortunately I'm not an OpenWRT expert, but looking somewhat deeper, among others AICCU depends on the modules kmod-sit, kmod-tun and kmod-iptunnel4. As far as I understand, my wan6/sixxs interface definition within /etc/config/network just defines the TUN/TAP device (provided by kmod-tun), while AICCU then attracts the other modules to form an IPv6/AYIYA/UDP/IPv4 or IPv6/IPv4 (heartbeat) tunnel according to information received via TIC. But sorry if I only tell trivial things here which don't answer your question.
root@OpenWrt:~# opkg info kmod-sit
Package: kmod-sit
Version: 3.6.8-1
Depends: kernel (= 3.6.8-1-b22ecb1214fc38c754cb8110b4383804), kmod-ipv6, kmod-iptunnel4
Provides:
Status: install hold installed
Section: kernel
Architecture: ar71xx
Maintainer: OpenWrt Developers Team <openwrt-devel@openwrt.org>
MD5Sum: 33f03f766f4af27b9c263e710fd5eecf
Size: 8879
Filename: kmod-sit_3.6.8-1_ar71xx.ipk
Source: RL:
Description: Kernel modules for IPv6-in-IPv4 tunnelling
Installed-Time: 1354574312
root@OpenWrt:~# opkg info kmod-tun
Package: kmod-tun
Version: 3.6.8-1
Depends: kernel (= 3.6.8-1-b22ecb1214fc38c754cb8110b4383804)
Provides:
Status: install hold installed
Section: kernel
Architecture: ar71xx
Maintainer: OpenWrt Developers Team <openwrt-devel@openwrt.org>
MD5Sum: 644dafaa066418710db71a1ba77e153b
Size: 10432
Filename: kmod-tun_3.6.8-1_ar71xx.ipk
Source: RL:
Description: Kernel support for the TUN/TAP tunneling device
Installed-Time: 1354574316
root@OpenWrt:~# opkg info kmod-iptunnel4
Package: kmod-iptunnel4
Version: 3.6.8-1
Depends: kernel (= 3.6.8-1-b22ecb1214fc38c754cb8110b4383804)
Provides:
Status: install hold installed
Section: kernel
Architecture: ar71xx
Maintainer: OpenWrt Developers Team <openwrt-devel@openwrt.org>
MD5Sum: 492a4c64ff8e23a3fe5e8f7b3c4c3496
Size: 2678
Filename: kmod-iptunnel4_3.6.8-1_ar71xx.ipk
Source: RL:
Description: Kernel modules for IPv4 tunneling
Installed-Time: 1354574316
IPv6 Firewall Issue on OpenWrt
Unfortunately I'm not an OpenWRT expert, but looking somewhat deeper, among others AICCU depends on the modules kmod-sit, kmod-tun and kmod-iptunnel4.
As far as I understand, my wan6/sixxs interface definition within /etc/config/network just defines the TUN/TAP device (provided by kmod-tun),
That is nearly impossible, as tun/tap devices are created by opening /dev/net/tun which creates a new tun or tap interface and the instructing it to rename the interface. As long as a PID has it open it will remain, when it quites though the tun/tap is dropped; this as only one process can have it open (well, likely more but that will be hard to do and very dirty coding work :)
while AICCU then attracts the other modules to form an IPv6/AYIYA/UDP/IPv4 or IPv6/IPv4 (heartbeat) tunnel according to information received via TIC.
Well, it answers that the process is not very transparent ;)
In short AICCU does:
- read config
- contact TIC, login using user/pass
- retrieve tunnel details from TIC
- based on the tunnel type: create a 6in4 tunnel (sit) or create a tun/tap interface by opening /dev/net/tun (or other devices on other platforms)
- configure the new interface
- loop, depending on tunnel type:
- static: just exit
- heartbeat: send them
- ayiya: read packets from tun send them as AYIYA, receive AYIYA and write those to tun
As such, any configuration done by another entity (be that a script or a human) might interfere in what AICCU wants to do, especially considering that AICCU does not have the ability to solve misconfigurations as those configurations might be intentional.
Thus, I am wondering what /etc/config/network really does; if it works though it means that it at least works for your heartbeat scenario, for AYIYA though that might be quite different.
IPv6 Firewall Issue on OpenWrt
Shadow Hawkins on Thursday, 06 December 2012 20:36:05
First of all, thanks for the numerous responses to my question.
My professor for computer networks suggested I should try pinging
a device in my network via Ipv6 from an outside network. I successfully
accomplished this by logging onto my server and pinging one of the
devices in my lan. This direction seems to be working fine.
Maybe this is a clue as to what is going wrong?
root@OpenWrt:~# sysctl -a |grep forwarding
sysctl: error reading key 'net.ipv4.route.flush': Permission denied
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.eth0.1.forwarding = 1
net.ipv4.conf.eth0.1.mc_forwarding = 0
net.ipv4.conf.eth0.2.forwarding = 1
net.ipv4.conf.eth0.2.mc_forwarding = 0
net.ipv4.conf.br-lan.forwarding = 1
net.ipv4.conf.br-lan.mc_forwarding = 0
net.ipv4.conf.sit0.forwarding = 1
net.ipv4.conf.sit0.mc_forwarding = 0
net.ipv4.conf.wlan0.forwarding = 1
net.ipv4.conf.wlan0.mc_forwarding = 0
net.ipv4.conf.mon.wlan0.forwarding = 1
net.ipv4.conf.mon.wlan0.mc_forwarding = 0
net.ipv4.conf.pppoe-wan.forwarding = 1
net.ipv4.conf.pppoe-wan.mc_forwarding = 0
net.ipv4.conf.sixxs.0.forwarding = 1
net.ipv4.conf.sixxs.0.mc_forwarding = 0
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.mc_forwarding = 0
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.default.mc_forwarding = 0
net.ipv6.conf.lo.forwarding = 1
net.ipv6.conf.lo.mc_forwarding = 0
net.ipv6.conf.eth0.forwarding = 1
net.ipv6.conf.eth0.mc_forwarding = 0
net.ipv6.conf.eth0.1.forwarding = 1
net.ipv6.conf.eth0.1.mc_forwarding = 0
net.ipv6.conf.eth0.2.forwarding = 1
net.ipv6.conf.eth0.2.mc_forwarding = 0
net.ipv6.conf.br-lan.forwarding = 1
net.ipv6.conf.br-lan.mc_forwarding = 0
net.ipv6.conf.sit0.forwarding = 1
net.ipv6.conf.sit0.mc_forwarding = 0
net.ipv6.conf.wlan0.forwarding = 1
net.ipv6.conf.wlan0.mc_forwarding = 0
net.ipv6.conf.mon.wlan0.forwarding = 1
net.ipv6.conf.mon.wlan0.mc_forwarding = 0
net.ipv6.conf.pppoe-wan.forwarding = 1
net.ipv6.conf.pppoe-wan.mc_forwarding = 0
net.ipv6.conf.sixxs.0.forwarding = 1
net.ipv6.conf.sixxs.0.mc_forwarding = 0
sysctl: error reading key 'net.ipv6.route.flush': Permission denied
root@OpenWrt:~# ip6tables -v --list -n
Chain INPUT (policy ACCEPT 13 packets, 13364 bytes)
pkts bytes target prot opt in out source destination
9 936 ACCEPT all * * ::/0 ::/0 state RELATED,ESTABLISHED
0 0 ACCEPT all lo * ::/0 ::/0
0 0 syn_flood tcp * * ::/0 ::/0 tcp flags:0x17/0x02
163 24496 input_rule all * * ::/0 ::/0
163 24496 input all * * ::/0 ::/0
Chain FORWARD (policy ACCEPT 2 packets, 112 bytes)
pkts bytes target prot opt in out source destination
26 1488 ACCEPT all * * ::/0 ::/0 state RELATED,ESTABLISHED
62 5008 forwarding_rule all * * ::/0 ::/0
62 5008 forward all * * ::/0 ::/0
Chain OUTPUT (policy ACCEPT 1 packets, 104 bytes)
pkts bytes target prot opt in out source destination
135 25908 ACCEPT all * * ::/0 ::/0 state RELATED,ESTABLISHED
0 0 ACCEPT all * lo ::/0 ::/0
105 7824 output_rule all * * ::/0 ::/0
105 7824 output all * * ::/0 ::/0
Chain forward (1 references)
pkts bytes target prot opt in out source destination
60 4896 zone_lan_forward all br-lan * ::/0 ::/0
0 0 zone_wan_forward all pppoe-wan * ::/0 ::/0
Chain forwarding_lan (1 references)
pkts bytes target prot opt in out source destination
Chain forwarding_rule (1 references)
pkts bytes target prot opt in out source destination
Chain forwarding_wan (1 references)
pkts bytes target prot opt in out source destination
Chain forwarding_wan6 (1 references)
pkts bytes target prot opt in out source destination
Chain input (1 references)
pkts bytes target prot opt in out source destination
149 10104 zone_lan all br-lan * ::/0 ::/0
0 0 zone_wan all pppoe-wan * ::/0 ::/0
Chain input_lan (1 references)
pkts bytes target prot opt in out source destination
Chain input_rule (1 references)
pkts bytes target prot opt in out source destination
Chain input_wan (1 references)
pkts bytes target prot opt in out source destination
Chain input_wan6 (1 references)
pkts bytes target prot opt in out source destination
Chain output (1 references)
pkts bytes target prot opt in out source destination
105 7824 zone_lan_ACCEPT all * * ::/0 ::/0
1 104 zone_wan_ACCEPT all * * ::/0 ::/0
1 104 zone_wan6_ACCEPT all * * ::/0 ::/0
Chain output_rule (1 references)
pkts bytes target prot opt in out source destination
Chain reject (4 references)
pkts bytes target prot opt in out source destination
56 4480 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset
4 416 REJECT all * * ::/0 ::/0 reject-with icmp6-port-unreachable
Chain syn_flood (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN tcp * * ::/0 ::/0 tcp flags:0x17/0x02 limit: avg 25/sec burst 50
0 0 DROP all * * ::/0 ::/0
Chain zone_lan (1 references)
pkts bytes target prot opt in out source destination
149 10104 input_lan all * * ::/0 ::/0
149 10104 zone_lan_ACCEPT all * * ::/0 ::/0
Chain zone_lan_ACCEPT (3 references)
pkts bytes target prot opt in out source destination
104 7720 ACCEPT all * br-lan ::/0 ::/0
149 10104 ACCEPT all br-lan * ::/0 ::/0
Chain zone_lan_DROP (0 references)
pkts bytes target prot opt in out source destination
0 0 DROP all * br-lan ::/0 ::/0
0 0 DROP all br-lan * ::/0 ::/0
Chain zone_lan_REJECT (1 references)
pkts bytes target prot opt in out source destination
0 0 reject all * br-lan ::/0 ::/0
60 4896 reject all br-lan * ::/0 ::/0
Chain zone_lan_forward (1 references)
pkts bytes target prot opt in out source destination
60 4896 zone_wan6_ACCEPT all * * ::/0 ::/0
60 4896 zone_wan_ACCEPT all * * ::/0 ::/0
60 4896 forwarding_lan all * * ::/0 ::/0
60 4896 zone_lan_REJECT all * * ::/0 ::/0
Chain zone_wan (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp * * fe80::/10 fe80::/10 udp spt:547 dpt:546
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 128 limit: avg 1000/sec burst 5
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 1 limit: avg 1000/sec burst 5
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 2 limit: avg 1000/sec burst 5
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 3 limit: avg 1000/sec burst 5
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 4 code 0 limit: avg 1000/sec burst 5
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 4 code 1 limit: avg 1000/sec burst 5
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 133 limit: avg 1000/sec burst 5
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 135 limit: avg 1000/sec burst 5
0 0 input_wan all * * ::/0 ::/0
0 0 zone_wan_REJECT all * * ::/0 ::/0
Chain zone_wan6 (0 references)
pkts bytes target prot opt in out source destination
0 0 input_wan6 all * * ::/0 ::/0
0 0 zone_wan6_REJECT all * * ::/0 ::/0
Chain zone_wan6_ACCEPT (2 references)
pkts bytes target prot opt in out source destination
Chain zone_wan6_DROP (0 references)
pkts bytes target prot opt in out source destination
Chain zone_wan6_REJECT (2 references)
pkts bytes target prot opt in out source destination
Chain zone_wan6_forward (0 references)
pkts bytes target prot opt in out source destination
0 0 zone_lan_ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 128
0 0 forwarding_wan6 all * * ::/0 ::/0
0 0 zone_wan6_REJECT all * * ::/0 ::/0
Chain zone_wan_ACCEPT (2 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all * pppoe-wan ::/0 ::/0
0 0 ACCEPT all pppoe-wan * ::/0 ::/0
Chain zone_wan_DROP (0 references)
pkts bytes target prot opt in out source destination
0 0 DROP all * pppoe-wan ::/0 ::/0
0 0 DROP all pppoe-wan * ::/0 ::/0
Chain zone_wan_REJECT (2 references)
pkts bytes target prot opt in out source destination
0 0 reject all * pppoe-wan ::/0 ::/0
0 0 reject all pppoe-wan * ::/0 ::/0
Chain zone_wan_forward (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 128 limit: avg 1000/sec burst 5
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 1 limit: avg 1000/sec burst 5
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 2 limit: avg 1000/sec burst 5
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 3 limit: avg 1000/sec burst 5
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 4 code 0 limit: avg 1000/sec burst 5
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 4 code 1 limit: avg 1000/sec burst 5
0 0 forwarding_wan all * * ::/0 ::/0
0 0 zone_wan_REJECT all * * ::/0 ::/0
IPv6 Firewall Issue on OpenWrt
I successfully accomplished this by logging onto my server and pinging one of the devices in my lan. This direction seems to be working fine.
The first thing one does when something does not work is to check the "Reporting Problems Checklist" on the contact page (as referenced by those big yellow/orange boxes when posting on the forum).
One major point there that is likely very relevant for you is that your firewall looks very wrongly configured.
But it depends on what you want to achieve of course with the firewall rules. Typically firewalls work really bad if you don't know what the rules really achieve.
Looking at the rules given though, it does not really make sense as there is some connection tracking in there, but there is no real acceptance or dropping of traffic.
I think the best step is to clear the firewall rules and then start over defining them, after testing that without them that things work.
Of course, the trend of firewalling is to do it in the endhosts and not in the middle of a network, exactly because of these kind of reasons: the network does not know what applications want.
|
![[ch]](/s/countries/ch.gif)
on Wednesday, 05 December 2012 12:56:34
Posting is only allowed when you are