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
> 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
> 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
> 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
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
>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
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.
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
> 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
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
