Project

General

Profile

Actions

Feature #12746

open

IPoE feature for WAN interface

Added by Anonymous almost 3 years ago. Updated 8 months ago.

Status:
New
Priority:
High
Assignee:
-
Category:
Interfaces
Target version:
-
Start date:
02/01/2022
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default

Description

I'd like to please request the addition of IPoE as a selection method for IPv6 WAN interface configuration.
The reason being, Japanese ISPs almost solely offer PPPoE for ipv4 and IPoE for ipv6.
The use case is encapsulating ipv4 over ipv6, which a Netgate engineer informed me is currently not an option within pfsense.

The engineer and I tried DHCP6, SLAAC, and 6 to 4 tunnel. There was a redmine post made a couple years ago but no development to my knowledge.

The netgate engineer suggested maybe the Japanese ISPs are using VLAN tagging as well.
In the end we were through trial and error, going through the options but none worked.
I was able to pull a v6 IP eventually, but the subnet was abnormally large, so likely it was just an error.
There are Japanese manufactured routers that support IPoE specifically from Buffalo and NEC however documentation as to how they're achieving this isn't clear or non-existant.

I'd be willing to be part of the beta testing should any devs wish to see what the environment is like for Japanese ISPs.

Thanks!!

Actions #1

Updated by Shaf S about 1 year ago

Hello Team,

Can anyone please advise if there is any traction on this issue/feature? Seems like this is preventing a lot of users to stay on with pfsense if in the Japan market as most of the ISPs are moving towards IPoE.

Appreciate any guidance on this.

Actions #2

Updated by Tianyi SUN 9 months ago

As far as I know, a significant portion of the supply in the Japanese market is using IPoE mode, and currently, almost all 10G network connections are using IPoE mode exclusively except NURO. I am using OpenWrt, which supports MAP-E and DS-Lite functionalities for connecting to IPoE. FreeBSD also has support for MAP-E and DS-Lite. I am not sure if it can be made into a plugin. I know a piece of BSD code, but I'm not sure if it would be helpful.

internal_net="192.168.0.0/24" # LANのアドレス
ext_if="tun0" # 外向きのインターフェース。ここではtun0になる
ext_if6="re0" # 外向きのインターフェース。IPv6
ext_if6br="bridge0"
int_if="em0" # 内向きのインターフェース
host_eagle="192.168.0.3" # 内部のNASサーバ

  1. Tables: similar to macros, but more flexible for many addresses.
    table <privates> { 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
    table <local> { 127.0.0.1, 192.168.0.1, 192.168.0.3 }
    table <special> const { 0/8, 14/8, 24/8, 39/8, 127/8, 128.0/16, 169.254/16, \
    192.0.0/24, 192.0.2/24, 192.88.99/24, 198.18/15, \
    223.255.255/24, 224/4, 240/4 }
    table <sshguard> persist
    table <blacklist> persist file "/etc/pf-blacklist.conf"
  1. 各種オプション(主にタイムアウト関係)
    #set timeout { interval 10, frag 30 }
    set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
    set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 }
    set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
    set timeout { icmp.first 20, icmp.error 10 }
    set timeout { other.first 60, other.single 30, other.multiple 60 }
    set timeout { adaptive.start 0, adaptive.end 0 }
    set limit { states 10000, frags 5000 }
    set loginterface tun0 # ログを取る対象のIF
    set optimization normal
    set block-policy drop # パケットを通さない(block)とき、 # RST(切断)を返さずそのまま捨てる
  2. Normalization: reassemble fragments and resolve or reduce traffic ambiguities.
    scrub in all
  1. Translation: specify how addresses are to be mapped or redirected.
    nat on $ext_if from $int_if:network to any -> ($ext_if) static-port
    rdr on $ext_if proto tcp from any to any port 8180 -> $host_eagle port 80
    rdr on $ext_if proto tcp from any to any port 8022 -> $host_eagle port 22

rdr-anchor "miniupnpd"

  1. Filtering: the implicit first two rules are
    anchor "miniupnpd"
  1. 基本ルールはすべてブロック
    block all
  1. block using blacklist
    block in log quick on $ext_if proto tcp from <blacklist> to any
    block in log quick on $ext_if proto tcp from <sshguard> to any port 22 label "ssh bruteforce"
    block in log quick on $ext_if6br inet6 proto tcp from <sshguard> to any port 22 label "ssh bruteforce"
    block in log quick on $int_if inet6 proto tcp from <sshguard> to any port 22 label "ssh bruteforce"
  1. ルーターから外に出るパケットはすべて許可
    pass out quick on $ext_if proto tcp all modulate state
    pass out quick on $ext_if proto udp all keep state
    pass out quick on $ext_if inet proto icmp all keep state

pass out quick on $ext_if6 inet6 proto tcp all modulate state
pass in quick on $ext_if6 inet6 proto tcp all modulate state
pass out quick on $ext_if6 inet6 proto udp all keep state
pass in quick on $ext_if6 inet6 proto udp all keep state
pass out quick on $ext_if6 inet6 proto icmp6 all keep state
pass in quick on $ext_if6 inet6 proto icmp6 all keep state

set skip on bridge0

  1. 外部からのssh,http,ntpを許可する
    #(ルーターでこれらのサービスを行なっている場合)
    pass in on $ext_if proto tcp from any to $ext_if port 22 flags S/SA modulate state
    pass in on $ext_if6 inet6 proto tcp from any to any port 22 flags S/SA modulate state
    pass in on $ext_if proto tcp from any to $ext_if port 80 flags S/SA modulate state
    pass in on $ext_if6 inet6 proto tcp from any to any port 80 flags S/SA modulate state
    pass in on $ext_if proto udp from any to $ext_if port 123 keep state
    pass in on $ext_if inet proto tcp from any to $host_eagle port {22, 80} synproxy state
    pass in on $ext_if inet proto tcp from any to $host_eagle port {22, 80} synproxy state
  1. Allow ICMP
    pass in quick on $ext_if inet proto icmp from any to any icmp-type echoreq keep state
  1. ルーターマシンのループバックを許可
    set skip on lo0
  1. ルーターとLAN内部との通信はすべて許可
    pass on $int_if all
Actions #3

Updated by Ryan H 8 months ago

While some Japanese ISPs may still offer PPPoE, the latency fluctuates quite a bit, especially during the evening.

My ISP (reseller of IIJ) offers both PPPoE (v4) or iPoE (v6) but with the PPPoE option, they do not offer IPv6 connectivity. I'm currently using a HE tunnelbroker GIF for IPv6 but still have the fluctuating latency on both IPv4 and IPv6.

Without native pfSense support of iPoE, users in Japan are stuck with a choice between IPv4-latency or IPv6-only from the ISP.

I would also like to volunteer as a beta tester. I've requested connection details from the ISP to determine if they use MAP-E or DS-Lite.

Actions

Also available in: Atom PDF