44net

44net@mailman.ampr.org

4 participants
3198 discussions

Mikrotik firewall rules for 44net?
by Nick G4IRX 10 Dec '16

10 Dec '16

I've recently installed Marius YO2LOJ's RIPv2 AMPR Gateway Setup Script 2.2 on a Mikrotik RB450G. RouterOS is version 6.37.3, I have 44.131.56.241 configured on the ucsd-gw interface and 44.131.56.9/29 on ether5 for my LAN. It seems to work well and I can access 44net hosts from a 44net machine on the LAN. I'm filtering traffic on the WAN interface of the router to only permit ipip traffic, however I still see traffic from outside 44/8 - mainly tcp syn packets to port 23 appearing on the LAN. These must be coming down via a tunnel and I'd like to filter them out. I've implemented an output rule to permit traffic from 44/8 to 44/8 and drop everything else, applied this to ether5. Is there a better way to implement this? I would like to filter on the WAN side but that would mean a firewall input rule on every tunnel. Thanks, -- Nick G4IRX

2 2

Re: [44net] Telnet To JNOS From Public IP Users Not Working
by Rob Janssen 10 Dec '16

10 Dec '16

> i was able to telnet in from here and got a login prompt from > wa4zlw.ampr.org Yes, from .ampr.org hosts it works OK. But the question was about "Public IP" users (he means users on the normal internet). That does not work, at least not here. When JNOS is running on Linux it is best to do the tunneling in Linux and have JNOS on a local subnet behind that. When running on another OS, it will be required to put a decent router inbetween. Rob

1 0

Re: [44net] Telnet To JNOS From Public IP Users Not Working
by Rob Janssen 10 Dec '16

10 Dec '16

> Your JNOS is trying to respond directly to the incoming connections rather > than traversing an encap tunnel. This will not work as the upstream > hardware does not know about you and your 44net allocation. You receive > packets over the encap bridge but you respond back directly. > As for how to fix it? Dunno. We need to somehow encap your outgoing default > route for your 44 IP address so that packet response is along the same path > that it came in. Is that the issue? When I telnet to him from internet I do get "established" suggesting that something gets back... But when it is as you write, what you need is "policy routing". that means, the capability to select a (default) route based on criteria like the source address (your 44-net address or your public IP address). The first has to go to amprgw, the second has to go to your ISP. Does JNOS even offer that? It can be solved with Linux or a sophisticated router like MikroTik or OpenWRT, but I am not sure a bare JNOS system can do this. Rob

2 1

Re: [44net] Telnet To JNOS From Public IP Users Not Working
by Rob Janssen 09 Dec '16

09 Dec '16

> Subject: > [44net] Telnet To JNOS From Public IP Users Not Working > From: > "Charles Hargrove" <n2nov(a)n2nov.net> > Date: > 12/09/2016 07:13 PM > > To: > 44net(a)hamradio.ucsd.edu > > > I am having trouble getting users to telnet from their homes to my JNOS box > located at 44.68.41.1 on port 2300. Their seems to be an asynchronous > connections as they try to transverse the UCSD portal. I see my responses > going back to them, but they are just hanging on their side. I have in my > autoexec.nos file "route add default tun1 44.0.0.1" as their is a tunnel > interface between the JNOS and the linux box that it is running on. Does > anyone have any ideas? Thanks. I get a connect but no text. Normally this means there is an MTU issue somewhere, but in this case (trying from net-44) the welcome text appears to be too smal for that kind of problem. it could be a firewall issue as well. Why do you set the default route to 44.0.0.1 instead of 169.228.66.251 ? Is that normal for JNOS? Rob

4 3

Telnet To JNOS From Public IP Users Not Working
by Charles Hargrove 09 Dec '16

09 Dec '16

I am having trouble getting users to telnet from their homes to my JNOS box located at 44.68.41.1 on port 2300. Their seems to be an asynchronous connections as they try to transverse the UCSD portal. I see my responses going back to them, but they are just hanging on their side. I have in my autoexec.nos file "route add default tun1 44.0.0.1" as their is a tunnel interface between the JNOS and the linux box that it is running on. Does anyone have any ideas? Thanks. -- Charles J. Hargrove - N2NOV NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Net Mon. @ 8:30PM 449.025/123.0 PL http://www.nyc-arecs.org and http://www.nyc-skywarn.org NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB/1500 hz waterfall spot; Olivia 8/500 check-ins "Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan "The more corrupt the state, the more it legislates." - Tacitus "Molann an obair an fear" - Irish Saying (The work praises the man.) "No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan "We are fast approaching the stage of ultimate inversion: the stage where the government is free to do anything it pleases, while the citizens may act only by permission." - Ayn Rand

1 0

Re: [44net] LoRa
by Steve L 27 Nov '16

27 Nov '16

>Are hams allowed to use spread spectrum modes in USA? Yes. Speaking of rules... I once asked about data data rates and bandwidth rules for ham radio in other countries. I am interested in learning about spread spectrum rules, and encryption rules for the hobby in other areas for anyone who cares to share. Steve KB9MWR

2 1

Re: [44net] LoRa
by Steve L 27 Nov '16

27 Nov '16

Dean, Thanks for sharing. Range will be the big thing at least for me, so if you get around to testing that, I hope you'll share your results. Though I am really leaning toward the 400 MHz modules. If there continues to be hold up on the MMDVM boards, then I'll likely order some LoRa modules for my winter project instead.

1 0

LoRa
by Steve L 27 Nov '16

27 Nov '16

Since we really need some other data radio options in the hobby, I wanted to mention LoRa. It's a chirped spread spectrum technology used for low power WAN applications, with air transfer rates: 300bps-31.2Kbps. There are 433 MHz modules, as well as 900 MHz and 2.4 GHz. As a staring place, WA2KWR has some code here: https://github.com/fcolumbu/LoRa_Projects/wiki Steve, KB9MWR

2 1

Re: [44net] LoRa
by Rob Janssen 27 Nov '16

27 Nov '16

> Since we really need some other data radio options in the hobby, I > wanted to mention LoRa. > It's a chirped spread spectrum technology used for low power WAN > applications, with air transfer rates: 300bps-31.2Kbps. There are 433 > MHz modules, as well as 900 MHz and 2.4 GHz. Indeed it is interesting, I have looked at it as well when a local telecom company recently announced it has deployed a country-covering network. (by mounting LoRa equipment at all cell towers and locations) They use 900 MHz, which is not a ham band here. But 433 could be useful. It is unfortunate that the datarate is too low for many applications. It could be interesting for APRS-like mobile datacomm or other telemetry, which is also what the commercial network is for. Rob

2 1

postfix/smtp/smtpd flood...
by SP2L 23 Nov '16

23 Nov '16

Greetings. Lately my small amateur server been severely flooded with similar activities: Nov 21 22:54:01 linux postfix/smtp/smtpd[26048]: connect from unknown[200.7.249.218] Nov 21 22:54:02 linux postfix/smtp/smtpd[26048]: disconnect from unknown[200.7.249.218] Nov 21 22:55:01 linux postfix/smtp/smtpd[26048]: connect from unknown[83.70.149.33] Nov 21 22:55:04 linux postfix/smtp/smtpd[26048]: disconnect from unknown[83.70.149.33] Nov 21 22:56:59 linux postfix/smtp/smtpd[26066]: connect from mail.devaney.net[96.91.214.49] Nov 21 22:57:00 linux postfix/smtp/smtpd[26066]: disconnect from mail.devaney.net[96.91.214.49] Nov 21 23:00:11 linux postfix/smtp/smtpd[26161]: connect from unknown[83.70.149.33] Nov 21 23:00:11 linux postfix/smtp/smtpd[26161]: disconnect from unknown[83.70.149.33] Nov 21 23:02:27 linux postfix/smtp/smtpd[26203]: connect from unknown[186.33.182.12] Nov 21 23:02:28 linux postfix/smtp/smtpd[26203]: disconnect from unknown[186.33.182.12] Nov 21 23:02:31 linux postfix/smtp/smtpd[26203]: connect from unknown[unknown] Nov 21 23:02:31 linux postfix/smtp/smtpd[26203]: disconnect from unknown[unknown] Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: connect from unknown[50.126.82.18] Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: lost connection after HELO from unknown[50.126.82.18] Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: disconnect from unknown[50.126.82.18] System logs were building up very fast! Created new entries for fail2ban porogram and got rid of this in a few minutes time! In jail.local file added: [postfix-auth] enabled = true filter = postfix.auth action = iptables-multiport[name=postfix, port="http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve", protocol=tcp] logpath = /var/log/mail.log In filter.d folder added new filter postfix.auth.conf with regex: # failregex = ^%(__prefix_line)slost connection after (AUTH|UNKNOWN|EHLO) from (.*)\[<HOST>\].* ^%(__prefix_line)sconnect from unknown\[<HOST>\].* ^%(__prefix_line)swarning: hostname.* ignoreregex = # >From now on NO MORE such crap!!! Best regards. Tom - SP2L

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net