These are the rules that route AMPRNet traffic to and from the ipip daemon (FreeBSD ipfw syntax):
# # AMPR routing # # table(1) contains all registered/routable 44net addrs. # table(2) contains all registered gateways.
# outbound encapsulated packets # should go only to registered gateways 00100 allow ipencap from me to 'table(2)'
# inbound encapsulated packets # should only come from registered gateways 00200 allow ipencap from 'table(2)' to me
# filter the 44net input side of things # valid destination addresses go to the router socket: ipipd 00300 divert 4444 ip from any to 'table(1)' in not dst-port 111,135-139,445,1025-1028,1900,2323,5353,7547
# filter the 44net output side of things 00400 allow ip from 'table(1)' to any
Explanation:
Preliminary filtering of incoming packets is done by the BSD ipfw firewall because it's easy to set up and very fast. Quite a bit more filtering is done by the ipip router daemon.
Ipfw table 1 contains a list of the 44-net host addresses from the AMPR.ORG DNS zone file that are routable according to the encap file. Table 2 contains a list of the gateways from the encap file.
Once an hour, the AMPR.ORG DNS zone file is fetched, normally at 10 minutes past the hour. Also hourly, the encap file is fetched from the portal, normally at 20 minutes past the hour. Whenever these files differ from their previous version, the ipfw tables are flushed and reloaded. When the encap file changes, the ipipd routing and the rip sender tables are also reloaded.
Rule 100 allows the encapped packets out to registered gateways.
Rule 200 allows encapped packets in only from registered gateway source addresses.
Rule 300 diverts incoming IP to the ipipd encapsulating router if the destination address is for a registered/routed address and not for certain destination ports.
Rule 400 allows outgoing IP with source addresses from registered/routed hosts.
That's about all the filtering that can be done without looking inside the encapped packets, which the BSD firewall can't do. The ipipd daemon handles that, and is much stricter. - Brian
On Tue, Apr 25, 2017 at 10:11 AM, Brian Kantor Brian@ucsd.edu wrote:
These are the rules that route AMPRNet traffic to and from the ipip daemon (FreeBSD ipfw syntax):
# # AMPR routing # # table(1) contains all registered/routable 44net addrs. # table(2) contains all registered gateways.
# outbound encapsulated packets # should go only to registered gateways 00100 allow ipencap from me to 'table(2)'
# inbound encapsulated packets # should only come from registered gateways 00200 allow ipencap from 'table(2)' to me
# filter the 44net input side of things # valid destination addresses go to the router socket: ipipd 00300 divert 4444 ip from any to 'table(1)' in not dst-port 111,135-139,445,1025-1028,1900,2323,5353,7547
# filter the 44net output side of things 00400 allow ip from 'table(1)' to any
Is there a default deny rule?
Tom KD7LXL
Yes, of course. It's the last rule in the set, and much further down the list after all the rules that allow access to the host processes (web server, etc) themselves. Those aren't relevant to AMPR routing so I didn't post them. - Brian
On Tue, Apr 25, 2017 at 10:15:29AM -0700, Tom Hayward wrote:
Is there a default deny rule?
Thank you for sharing ....
If you block incoming MS network Protocole why dont you block it outgoing as well ?
________________________________
# filter the 44net input side of things # valid destination addresses go to the router socket: ipipd 00300 divert 4444 ip from any to 'table(1)' in not dst-port 111,135-139,445,1025-1028,1900,2323,5353,7547
Rule 300 diverts incoming IP to the ipipd encapsulating router if the destination address is for a registered/routed address and not for certain destination ports.
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Interesting idea. We could. I'll look into it. At the time, I was only interested in protecting AMPRNet, not the rest of the Internet, but it would be a good neighbor thing to do. - Brian
On Tue, Apr 25, 2017 at 05:28:13PM +0000, R P wrote:
If you block incoming MS network Protocole why dont you block it outgoing as well ?
The Ms Network is a Noise generator (specially the broadcast and MS naming system) I remember that long ago you blocked it to reduce un neccessary noise (i myself prefer allowing to do MS Network even in the price of some exessive noise ... ) so if it doesnt work now blocking it the other direction can reduce more un nessessary White noise even your outgoing channel (dont know how big is your bandwith there)
________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of Brian Kantor Brian@UCSD.Edu Sent: Tuesday, April 25, 2017 10:34 AM To: AMPRNet working group Subject: Re: [44net] Revised amprgw firewall rules
(Please trim inclusions from previous messages) _______________________________________________ Interesting idea. We could. I'll look into it. At the time, I was only interested in protecting AMPRNet, not the rest of the Internet, but it would be a good neighbor thing to do. - Brian
On Tue, Apr 25, 2017 at 05:28:13PM +0000, R P wrote:
If you block incoming MS network Protocole why dont you block it outgoing as well ?
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Outgoing bandwidth is fairly good - amprgw is connected to the rack switch with a 1 Gb/s Ethernet, the rack switch is connected to the building with 10 GbE, and the building is connected to the outside world at 100 GbE. We're looking into upgrading the 1 GbE to 10 GbE at some point. - Brian
On Tue, Apr 25, 2017 at 05:42:03PM +0000, R P wrote:
The Ms Network is a Noise generator (specially the broadcast and MS naming system) I remember that long ago you blocked it to reduce un neccessary noise (i myself prefer allowing to do MS Network even in the price of some exessive noise ... ) so if it doesnt work now blocking it the other direction can reduce more un nessessary White noise even your outgoing channel (dont know how big is your bandwith there)
-
Brian Kantor -
R P -
Tom Hayward