Hello Everyone,
I'm helping out a local HAM getting an IPIP AMPR setup working but his
current AT&T Uverse / Pace s 5862ac unit doesn't seem to be playing
nicely. Yeah.. I know.. Shocking! Anyway, touter/NAT mode seems to
*only* want to forward TCP/UDP protocols (typical) and it's DMZPlus
feature mode seems to be breaking his Wifi network. As we maybe hack
with the DMZplus feature tomorrow, I was curious if there is anyone
willing to offer up a VPN connection to his Raspberry Pi as a Plab-B:
Looking through the archives, there was
http://wiki.ampr.org/index.php/AMPRNet_VPN but that link is 404. I know
there is also the http://wiki.ampr.org/wiki/AMPRNet_VPN link but I know
other HAMs are/were offering less complicated setups. I can help him
setup any offering be it IPSEC, SSL-VPN, etc. He's not looking for any
sort of performance.. just general IPIP access to play around, etc. at
the moment.
If already hosting or you're willing to host a solution, let me know.
Thanks!
--David
KI6ZHD
All the examples I have found have a static public ip, is there a way to do it with a dynamic public ip, my ISP does not assign statics to residential customers.
cantantes laudat orbis terrarum
I have followed the directions in http://lz4ny.eu/en/amprnet-44-rip/ to setup my GW, but all I get when I run ampr-ripd is the following
root@thor:/home/w0kcf# ampr-ripd -d -i tunl0
Using gateway 192.168.1.1 for direct 44net endpoints via interface enp0s18.
Waiting for RIPv2 broadcasts...
Network configuration is as follows
w0kcf@thor:~$ ifconfig
enp0s10 Link encap:Ethernet HWaddr 00:14:6c:81:ff:fe
inet addr:44.26.1.80 Bcast:44.26.1.95 Mask:255.255.255.240
inet6 addr: fe80::214:6cff:fe81:fffe/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16335 errors:0 dropped:10870 overruns:0 frame:0
TX packets:58 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1273233 (1.2 MB) TX bytes:6874 (6.8 KB)
enp0s18 Link encap:Ethernet HWaddr 00:13:8f:7a:c8:aa
inet addr:192.168.1.9 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::213:8fff:fe7a:c8aa/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:23028 errors:0 dropped:0 overruns:0 frame:0
TX packets:17964 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6155448 (6.1 MB) TX bytes:2789754 (2.7 MB)
What am I missing?
73
Kevin W0KCF
Hello,
Mikrotik released its new RouterOS version 6.41, with some changes
affecting the gateway script.
I released an updated script version to address this issue.
For those using pre-6.41 ROS, the update is not necessary.
If you want to correct the script manually, just delete the line
referring to neighbor discovery disabling in the 'add new tunnel'
section of the ampr_gw script whic states:
/ip neighbor discovery set $gw discover=no
As usual, download at:
http://www.yo2loj.ro/hamprojects/http://yo2tm.ampr.org/hamprojects/
Marius, YO2LOJ
Currently running on a Raspberry Pi in a pfSense DMZ on residential Dynamic
IP. Marius’ ampr-ripd compiled with no issue, the scripts from my linux
gateway that I worked on with Lynwood work perfectly with no modification.
Need to do a little tweaking with iptables firewall as my network
implementation is different from what it was when I was running one box.
Diagram:
(Internet)===<pfSense>==(DMZ)==<Raspberry Pi>==(44.98.63.0/29)
- I’m NAT forwarding ipip traffic that hits the pfSense external interface
to the DMZ (usb NIC) interface on the Pi.
- tunnel script and ampr-ripd run on the pi creating tunl0 on the pi
- local AMPR segment on the Pi native interface.
- pfSense NATs outbound encapsulated traffic making it appear as if it
comes from the pfSense box.
- My gateways appears on Marius map.
Working on documentation for the wiki and will post by weeks end.
—tom
--
73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified
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
