Dean Agreed RE: getting the edge firewalls in place. Cory is right that we don't really want to do it until we have some system in place for users to update their rules, but not knowing how long that will be, perhaps I'll bring up with the admins what we think of having it be manual, and the requests coming via emails for now. Regarding the connection issues, it's been raining the past couple of days, and coupled with your weaker end signal strength to begin with, that's what's bumping you. In fact the same thing happens to my link. I look through some trees, and when it rains in any significant amount, my link can drop by up to 15db or so (which at that point I lose connection). I wouldn't be surprised as today is supposed to be somewhat dryer, that it comes back today, and then gets lost again as it starts to rain again over the next few days. RE the firewall, if you like I can set up a block at the edge for you IP now if you prefer, and if so, let me know off list what services you'd like to keep open if any, which should take care of your russian friend. Nigel K7NVH On Mar 17, 2014, at 12:13 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote:
Well, I think you are going to have to do something about outside incoming traffic fairly soon.
I run "/interface wireless monitor 0", it usually shows the last IP address of 195.218.200.205 (Russia). I've got the default radio firewall enabled, so the only traffic I should see are unsuccessful port probes (or perhaps ICMP traffic).
If I run constant pings, when I set the ping interval to one second, my pings predominate, but with a ping interval of two seconds or more, the above IP predominates.
I don't know how much data he's sending, but today I'm having a hard time keeping any connection. I didn't have this problem before this past weekend, and I've made no configuration or location change: This morning, to help reestablishing a connect, I created a new scan list with only the Paine sector aimed toward me, and I'm using that to reduce the delay in reconnections.
Note that currently I'm not trying to do anything useful; I've got a poor antenna location (but it did work reasonably well until today). Hopefully in a day or two, I will have a better (outside and higher) temporary location.
If you temporarily give me a different IP address, I can try that to see if I'm the only one he's pounding on. I doubt that I am.
-- Dean
On 2014-03-16 10:05, Cory (NQ1E) wrote:
The current plan is to block all unsolicited incoming traffic from the internet on the edge routers before it gets to the RF portions of the network. However, we don't want to do that until we have automation in place to maintain those rules and until we have a self-service way for you to poke holes in that configuration should you want to allow incoming traffic from the world to one of your IP addresses. If you want to block traffic from all sources (including other hams), then adding firewall rules to your own device is the correct way to accomplish that.
The rules are well established for auto-patches that connect voice repeaters to the PSTN. Even incoming telephone calls are allowed as long as they are "expected" by the ham. Because the parallels between these systems are fairly clear, the plan above puts us in the best position to make sure our users are able to maintain their part 97 compliance.
On Sat, Mar 15, 2014 at 11:25 PM, Dean Gibson AE7Q <hamwan@ae7q.net> wrote: OK, after seeing the number of "random" IP addresses hitting the radio from outside the 44.0.0.0 net, I didn't like the fact that the firewall filters were removed in the web site's suggested configuration, so I decided to start from scratch. I learned a couple things ...
# -- Restore the radio to a factory fresh state -- /system reset
# === At this point you must connect via MAC address === /user set admin password="This is not it ..." /console clear-history /system identity set name="CALL-Paine"
/ip dns set allow-remote-requests=no address remove [find]
/ip firewall mangle add action=change-mss chain=output new-mss=1378 protocol=tcp tcp-flags=syn tcp-mss=!0-1378 add action=change-mss chain=forward new-mss=1378 protocol=tcp tcp-flags=syn tcp-mss=!0-1378
/ip dhcp-server remove [find] network remove [find]
/ip dhcp-client add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=ether1 use-peer-dns=no # -- The following is already configured -- #add add-default-route=yes dhcp-options=hostname,clientid disabled=no interface=wlan1
# -- Do the following if you need to move the radio to a different network -- /system shutdown
# === At this point you can connect via IP address === /system logging action set remote bsd-syslog=yes remote=my.lcl.log.svr remote-port=514 src-address=my.lcl.ether.ip syslog-facility=local1 syslog-severity=info add action=remote disabled=no prefix="" topics=!debug,!snmp
Note that I have "bsd-syslog" set to "yes". This appears to be necessary if you want a remote system to see "syslog-facility" and "syslog-severity" (the radio doesn't save/display those settings otherwise).
/system ntp client set enabled=yes mode=unicast primary-ntp=my.lcl.ntp.svr1 secondary-ntp=my.lcl.ntp.svr2
/interface wireless channels add band=5ghz-onlyn comment="Cell site sector centered at 360 degrees" frequency=5920 list=HamWAN name="Sector300-060" width=5 channels add band=5ghz-onlyn comment="Cell site sector centered at 120 degrees" frequency=5905 list=HamWAN name="Sector060-180" width=5 channels add band=5ghz-onlyn comment="Cell site sector centered at 240 degrees" frequency=5890 list=HamWAN name="Sector180-300" width=5 /delay 5 set 0 radio-name="CALL/Location-Paine" set 0 disabled=no frequency-mode=superchannel scan-list=HamWAN ssid=HamWAN wireless-protocol=nv2
/tool dns-update dns-server=my.lcl.dns.svr key="MD5 key ..." key-name=ddns ttl=3600 zone=ae7q.net name=hamwan-1 address=my.ham.wan.ip /console clear-history
monitor 0
I like my sector names better than just numbers...
These "scripts" (when altered) can just be pasted into a command window (otherwise the "/delay 5" above is not necessary).
Oh, I can sometimes connect through my CLOSED window, but that's not reliable enough for anything useful.
-- Dean
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org