Hi Tom,
Some tome ago I was fiddling with pfSense to make it my gateway. I
abandoned this idea because there was a couple of key issues for me:
- BSD needs a device for each IPIP tunnel, this gets the things much
more harder to setup;
- PfSense does not have the protocols used enabled by default, needing
manual edit of the web interface after each update. You have to do it by
yourself every time;
- Linux has ready made scripts to get the job done. These scripts were
made by good hams here and tested by several other people. It is easier
to create a small virtual machine and put a 256MB RAM Devuan working
than creating a gateway using BSD.
- PfSense team is minded to get the commercial way of pfSense as a
product, so do not expect any support to get the things working. Their
support forum is getting more unconcerned every day.
If you are still inclined to use some type of BSD firewall as an AMPRNet
gateway, I suggest using OPNSense to start. It was a project forked from
pfSense, but today have only 10% of original code and have open source
as priority yet. Their forum is much more friendly and responsive.
OPNSense has all protocols listed in the web interface, so passing IPIP
traffic back and forth is more intuitive (I still would not use it as a
gateway anyway).
Hope this helps,
73 de PT2LDR
Luzemario
www.luzehost.com.br
Em 06-01-2018 18:00, 44net-request(a)mailman.ampr.org escreveu:
> Greetings,
> I was working with Dan Cooper last spring to turn my pfSense box into
> an ampr gateway. At the time I was trying to learn how IPIP worked AND
> how BSD (pfSense) worked. I'm pretty well versed in linux... BSD...
> not so much.
>
> At the time I moved to Linux and Lynwood helped me get my head around
> how the IPIP tunneling works. After seeing the volume of traffic that
> tries to crack into my residential ISP connection (even though it
> fails) I've decided to put my ampr gateway into a DMZ. I'm currently
> in the process of moving my AMPR gateway into a pfSense DMZ.
>
> I work in a loosely security related position at work and I'm doing
> this as a security measure to knock down some of the noise my Linux
> gateway/Router/Firewall/AMPRgateway was seeing, mostly from Russia,
> China and other places that I didn't research. My new AMPR gateway
> will still be on Linux, actually Raspbian on a Raspberry Pi, but the
> only traffic it'll ever see is encapsulated traffic and traffic from
> my network because all of the other noise will be filtered by the
> pfSense box and won't exist in my DMZ.
>
> Out of the box the pfSense user interface doesn't have support for
> ipencap or AX25. I did a little bit of research (google) and found an
> older post on the pfsense forum about which files to edit to add
> ipencap and ax25 to the UI. Also, I just asked on the pfSense
> subreddit to see if there are any other places within the pfSense UI
> to edit which protocols are available for use.
>
> Is anyone else using this method to NAT forward IPIP traffic to an
> internal gateway (in my case using pfSense). I'm looking to find out
> if I've missed anything with the port forwarding before I move
> forward. I know Brian (N1URO) was working with IPIP tunneling behind a
> NAT and I think (THINK) this might work.
>
> So... here's what I've done.
>
> pfSense version is 2.4.2p1. File edits follow...
>
> In file:
> /usr/local/www/firewall_nat_edit.php
>
> On line 708, change:
> $protocols = "TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP PIM OSPF";
>
> To:
> $protocols = "TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP PIM OSPF
> IPENCAP AX25";
>
> In file:
> /usr/local/www/firewall_nat_out_edit.php
>
> On line 510, change:
> $protocols = "any TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP carp pfsync";
>
> To:
> $protocols = "any TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP carp
> pfsync IPENCAP AX25";
>
> In file:
> /usr/local/www/firewall_rules_edit.php
>
> Insert as line 1315 and 1316:
> 'ipencap' => 'IPENCAP',
> 'ax25' => 'AX25',
>
> --
> Tom / n2xu / MSgt USAF (Ret) / BSCS, CASP
Greetings,
I was working with Dan Cooper last spring to turn my pfSense box into an
ampr gateway. At the time I was trying to learn how IPIP worked AND how
BSD (pfSense) worked. I'm pretty well versed in linux... BSD... not so
much.
At the time I moved to Linux and Lynwood helped me get my head around
how the IPIP tunneling works. After seeing the volume of traffic that
tries to crack into my residential ISP connection (even though it fails)
I've decided to put my ampr gateway into a DMZ. I'm currently in the
process of moving my AMPR gateway into a pfSense DMZ.
I work in a loosely security related position at work and I'm doing this
as a security measure to knock down some of the noise my Linux
gateway/Router/Firewall/AMPRgateway was seeing, mostly from Russia,
China and other places that I didn't research. My new AMPR gateway will
still be on Linux, actually Raspbian on a Raspberry Pi, but the only
traffic it'll ever see is encapsulated traffic and traffic from my
network because all of the other noise will be filtered by the pfSense
box and won't exist in my DMZ.
Out of the box the pfSense user interface doesn't have support for
ipencap or AX25. I did a little bit of research (google) and found an
older post on the pfsense forum about which files to edit to add ipencap
and ax25 to the UI. Also, I just asked on the pfSense subreddit to see
if there are any other places within the pfSense UI to edit which
protocols are available for use.
Is anyone else using this method to NAT forward IPIP traffic to an
internal gateway (in my case using pfSense). I'm looking to find out if
I've missed anything with the port forwarding before I move forward. I
know Brian (N1URO) was working with IPIP tunneling behind a NAT and I
think (THINK) this might work.
So... here's what I've done.
pfSense version is 2.4.2p1. File edits follow...
In file:
/usr/local/www/firewall_nat_edit.php
On line 708, change:
$protocols = "TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP PIM OSPF";
To:
$protocols = "TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP PIM OSPF IPENCAP
AX25";
In file:
/usr/local/www/firewall_nat_out_edit.php
On line 510, change:
$protocols = "any TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP carp pfsync";
To:
$protocols = "any TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP carp pfsync
IPENCAP AX25";
In file:
/usr/local/www/firewall_rules_edit.php
Insert as line 1315 and 1316:
'ipencap' => 'IPENCAP',
'ax25' => 'AX25',
--
Tom / n2xu / MSgt USAF (Ret) / BSCS, CASP
> You can, but please do not.
> It will enable neighbor discovery on new tunnels, which is not desired
> and creates useless traffic.
> There are no functional changes except this.
> Marius, YO2LOJ
When researching this matter (I wanted to enable neighbor discover on new L2TP tunnels
internal to our network) I found that this command line can disable it by default:
/ip neighbor discovery settings set default=no default-for-dynamic=no
The "default" is for manually created interfaces like IPIP tunnels, the "default-for-dynamic"
is for dynamic interfaces like the server-side of L2TP tunnels.
With this command issued once, the discovery should be off on new tunnels on versions < 6.41
However, this command no longer exists in 6.41 !
Now, setting of discovery is done using an interface list with the members of the list
participating in discovery (or the non-members, there is an inversion operator)
So look in the "ip neighbor" discovery settings to see how the interfaces are now set,
there can be an interface list "discover" (the new default) or there can be something
like "!dynamic" which results in discovery on all non-dynamic interfaces (the old default).
When it says "!dynamic" it is better to change that to "discover" and put only your local
interfaces in that list.
Rob
Good afternoon,
I was updating my 44net IPIP Gateway and I noticed I received OSPF Multicast traffic from 44.162.0.1:
OSPF hlo (a=254 r=44.162.254.33) (76 bytes) from 44.162.0.1 to 224.0.0.5 on ampr0
Could the OP please de-activate OSPF (or set as passive) on the IPIP interfaces?
Vy 73 and merry Christmas de Marc, LX1DUC
What are the differences between RIP44 and RIP v2? Is the RIP44
protocol documented anywhere? I'm learning more and would like to crack
into the differences between the protocols.
--tom
n2xu
I am retiring from UCSD, after 47 years on campus.
My new mailbox is brian _AT_ bkantor.net.
Future emails from me will usually come from there, although some may
come from my @ucsd.edu address for the next few weeks as I transition
various functions to the new mailbox.
The old UCSD address will forward to it for a while.
I will continue to use the @ampr.org address for some AMPRNet and ARDC
business.
Amprgw (gw.ampr.org) will continue to operate as it has for some time
as part of the CAIDA research group continuing measurement and analysis
of dark networks project. No changes in its operation are planned.
I will still be managing the amprnet-related portions of the amprgw
system, and AMPRNet in general, as before.
This mailing list will not be affected, as it is not hosted at UCSD.
- Brian
Those of you in the USA (and elsewhere) who are providing networking
services or connectivity to others should be aware of possible
liability under the DMCA (Digital Millenium Copyright Act) and
similar laws in other countries should one of the people you are
providing service to misbehave and commit a copyright violation,
such as posting copyrighted material on your or their own server,
or operating a peer-to-peer (BitTorrent, etc) node that is distributing
copyrighted material. It could be expensive.
I recommend you read up on this. A place to start is the Wikipedia
article on the OCILLA (Online Copyright Infringement Liability
Limitation Act).
https://en.wikipedia.org/wiki/Online_Copyright_Infringement_Liability_Limit…
Best wishes for a happy holiday season to all.
- Brian
What steps should be taken to get a hold of my coordinator? I've been
trying to get my block back in order for over a month now and I've not made
any progress at all.
Thanks
KD4CBM
Hi All,
I am sure that this question is asked by many newbies but I have to ask it to bring up my gateway... :)
I set up a gateway and coordinated the ip allocation with my regional IP coordinator.
But, however, testing behind NAT or without NAT (directly machine connected to internet (a server on a colaction ISP)) didn't have success..
using ampr-ripd with compiled DEBUG options I cant get and response from the 44.0.0.1
For testting I just did
# ifconfig tunl0 up 44.176.200.1 netmask 255.255.255.255
and tried
#./ampr-ripd -d -v -i tunl0
the result is as follows but no success even if I wait for 2 hours...
IS THERE A WAY TO TEST THIS RIPD CONNECTION ? (a tool or sniffing with tcpdump..) HOW CAN I BE SURE THAT I AM DOING EVERTHING RIGHT ?
Do I have to do something for multicast domain (e.g. 224.0.0.9)
Thanks
Baris TA7W
DEBUG OUTPUT:
------------------------
Using metric 0 for routes.
Using TCP window 840 for routes.
Using routing table 'main' (254).
Can not open encap file for reading: /var/lib/ampr-ripd/encap.txt
Max list size: 1000 entries
Detected tunnel interface address: 44.176.200.1
Interface detected: lo, IP: 127.0.0.1
Interface detected: eth0, IP: 80.211.231.30
Interface detected: eth1, IP: 0.0.0.0
Interface detected: eth2, IP: 0.0.0.0
Interface detected: tunl0, IP: 44.176.200.1
Assigned tunnel interface index: 5
Local IPs:
127.0.0.1
80.211.231.30
44.176.200.1
NL sending request.
NLMSG: get route (26)
RTA type: 1 (8 bytes): 8 8 8 8
NL response received.
NLMSG: request new route/route info (24)
RTA type: 15 (8 bytes): 254 0 0 0
RTA type: 1 (8 bytes): 8 8 8 8
RTA type: 4 (8 bytes): 2 0 0 0
RTA type: 7 (8 bytes): 80 211 231 30
RTA type: 5 (8 bytes): 80 211 231 1
RTA type: 8 (28 bytes): 8 0 2 0 220 5 0 0 8 0 8 0 180 5 0 0 8 0 10 0 64 0 0 0
RTA type: 12 (36 bytes): 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
NL sending request.
NLMSG: get route (26)
RTA type: 1 (8 bytes): 80 211 231 1
NL response received.
NLMSG: request new route/route info (24)
RTA type: 15 (8 bytes): 254 0 0 0
RTA type: 1 (8 bytes): 80 211 231 1
RTA type: 4 (8 bytes): 2 0 0 0
RTA type: 7 (8 bytes): 80 211 231 30
RTA type: 8 (28 bytes): 8 0 2 0 220 5 0 0 8 0 8 0 180 5 0 0 8 0 10 0 64 0 0 0
RTA type: 12 (36 bytes): 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Using gateway 80.211.231.1 for direct 44net endpoints via interface eth0.
Setting routes (0).
Creating multicast RIP UDP listening socket.
Setting up multicast interface.
Waiting for RIPv2 broadcasts...
On Mon, Nov 27, 2017 at 10:42:22 AM, Christopher Allsop wrote:
>> Has the AMPRNet group considered/have they moved over to an online
>> group instead of a mailing list? Perhaps something like Groups.io
>> or even a Slack channel may provide some information. Even a Reddit
>> group would allow information to be archived and searched later on.
>> I've always found email groups to be difficult when you want to
>> search for answers to questions already asked.
On Mon, Nov 27, 2017 at 10:52 AM, Brian Kantor wrote:
> This subject has been discussed to death in this group recently
> and the decision was to stay with a mailing list.
I propose that we start a Google group that accesses the Yahoo! copy
of the rec.radio.amateur.digital Usenet archive and sends all
responses to a new Listserv located at the RSGB via RFC1149
encapsulation. That way, we get the best of all possible worlds: a
system that reflects ham radio's "can do" attitude and includes all
the best parts of the amateur radio and the pigeon fancier hobbies.
Bill, W4EWH
