NAT Forward Rules for other protocols: IPIP
kris.ke4ahr last edited by kris.ke4ahr
I noticed that in the drop-down box for a NAT forward rule, the following are listed:
Of notable exclusion is IPIP (type 4), which is very much in active use by 44net aka ampr.org.
I am of the opinion that if the protocol types are going to be limited to the top 12, the last option should be a custom or advanced option and a custom field number entered.
Without the ability to forward the IPIP tunnel to another host for processing or tunnel termination, that prevents any of the 44net users from being able to connect from behind a pfSense firewall and excludes pfSense from being used as a firewall by those folks.
44net is 126.96.36.199/8 across the entire world. 44/8 is world-routable and allocated, and that's a lot of possible users to disenfranchise.
0x61 97 ETHERIP Ethernet-within-IP Encapsulation (EoIP)
0x62 98 ENCAP Encapsulation Header
0x7C 124 IS-IS over IPv4
0x85 133 FC FCoE
This is apparently a well-enough known issue that Amprnet participants are distributing fixes among themselves: http://www.qsl.net/kb9mwr/wapr/tcpip/pfsense.html
macNCheeseB last edited by
I second this suggestion. I'm trying to work with some protocols not in that list (among the most important is SCTP). Firewall has a larger list, but NAT limits the possibility.
There isn't any specific reason I'm aware of we don't include more protocols there, except that few people have asked for them (or none at all).
Only special consideration is that only TCP and UDP have a concept of ports, everything else should just forward in. Same with rules, the list isn't exhausive mostly for convenience, but technically pf can forward/filter any valid protocol as far as I'm aware. No documented limits I could see.
We could suck in the contents of
/etc/protocolsand massage it into something usable and tack it on the end of the drop-down, perhaps.
How about people just adding the protocol number like the custom ports ?
Then we'd need a completely new GUI control that would allow both drop-down and text input (like we have for ports, for example), and that's a bit more complicated to get into. Also it's valid to specify the protocol names, and people are not as likely to remember the numbers compared to the names.