25 Apr
2017
25 Apr
'17
1:11 p.m.
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
25 Apr
25 Apr
1:15 p.m.
On Tue, Apr 25, 2017 at 10:11 AM, Brian Kantor <Brian(a)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
1:19 p.m.
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?
1:28 p.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
1:34 p.m.
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 ?
1:42 p.m.
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(a)hamradio.ucsd.edu> on behalf of Brian
Kantor <Brian(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
1:46 p.m.
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)
2768
days inactive
2768
days old
6 comments
3 participants
participants (3)
-
Brian Kantor -
R P -
Tom Hayward