Thanks everyone for the MTU discussion/ suggestions on the google issues. I’ll try adjusting the MTU.
The https issue only just started. I had a letsencrypt certificate and auto-renew screwed up and I haven’t had a chance to fix it. That wasn’t a problem when I started this google thread, so won’t be the main issue with google.
Roger.
VA7LBB
On May 9, 2019, at 04:35, Scott Nicholas <scott.nicholas(a)scottn.us> wrote:
>> However, I'm not convinced that this is the problem as the site works OK
>> for me over internet. Why wouldn't it work for Google then?
>
> We have to speculate somewhat..I don't know what the crawler uses for
> TCP stack. I know each OS is different in the ways it deals with MTU
> and blackholes.
> I did a wireshark capture on my Windows desktop and show a lot of
> black/red. I lowered my MTU by 40 and re-tried and there was lots of
> green.
> The TCP MSS coming from the web server was already lowered by 20. I
> don't know what it looks like on the far end. I'm also speculating
> that it's not getting ICMP or seeing a lower MSS for me.
>
> Another reason I saw red -- a few links point to HTTPS and it is not
> enabled. Fix that, and set a lower MTU on the host, and we'll at
> least fix *some* problem. Maybe not the Googling indexing one. :)
>
> Regards,
> Scott
>
Nate,
Sorry, I'll have to update that page to make it more clear. The
purpose of it for setting up your own Open VPN server that uses LoTW
certificates to mimic what Heikki is doing.
When you are running a sever then obviously you are in control of the
address range it offers as part of the dynamic assignment. When you
are the client/ end-user then obviously no.
Steve, KB9MWR
On Fri, May 10, 2019 at 7:27 PM Nate Sales via 44Net
<44net(a)mailman.ampr.org> wrote:
>
>
>
>
> ---------- Forwarded message ----------
> From: Nate Sales <nate.wsales(a)gmail.com>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Cc:
> Bcc:
> Date: Fri, 10 May 2019 17:24:47 -0700
> Subject: Re: [44net] VPN Question
> Thank you for explaining, I totally misunderstood the purpose. Either way,
> thanks for the quick responses, I really appreciate it. I was mainly
> looking at https://qsl.net/k/kb9mwr//wapr/tcpip/lotw-vpn.html which led me
> to believe that was possible.
> -Nate
>
>
> On Fri, May 10, 2019 at 2:28 PM Heikki Hannikainen <hessu(a)hes.iki.fi> wrote:
>
> >
> > Hi,
> >
> > No. If you're using ipencap to join the amprnet tunnel mesh, you don't
> > need to use my VPN service.
> >
> > If you use the VPN, you can't use ipencap at the same time.
> >
> > With the VPN you get a single tunnel to the Amprnet, and you'll be
> > assigned a dynamic 44.139.11.x IP address during the VPN session.
> >
> > It is not possible to route your own 44.x.y.z subnet via this VPN. You're
> > limited to communicating with the dynamic 44.139.11.x address assigned to
> > you by the VPN server. Sorry!
> >
> >
> > On Fri, 10 May 2019, Nate Sales wrote:
> >
> > > Ok thank you! So the ip in the 44.139.11.x range becomes the gateway,
> > then
> > > just set up ipencap like normal?
> > > -Nate
> > >
> > > On Fri, May 10, 2019 at 8:29 AM Heikki Hannikainen <hessu(a)hes.iki.fi>
> > wrote:
> > >
> > >> On Thu, 9 May 2019, Ruben ON3RVH wrote:
> > >>
> > >>> If the subnet is routed to the openvpn server, the openvpn server can
> > >>> route that network to the endpoint.
> > >>
> > >> This particular openvpn server (that I run) does not offer such a
> > service.
> > >> It allows you to get connected to AMPRnet, but I don't have the time to
> > do
> > >> custom configurations to route subnets or do other per-user manual
> > >> tweaking at this time.
> > >>
> > >> So, Rob's "You can't" answer is correct. You'll get the dynamic
> > >> 44.139.11.x IP address and you can use that to communicate with the
> > >> amprnet. Sorry!
> > >>
> > >> - Hessu
> > >>
> > >>
> > >>> On 9 May 2019, at 11:14, Rob Janssen <pe1chl(a)amsat.org> wrote:
> > >>>
> > >>>>> I cant figure out where to go
> > >>>>> from here. Can anyone point me in the right direction in how to get
> > the
> > >>>>> routes set up for my little subnet?
> > >>>>
> > >>>> You can't.
> > >>>> Such a VPN offers you a connection, with an IP, and routes traffic for
> > >> that IP to you.
> > >>>> You cannot route arbitrary subnets over that because you cannot setup
> > >> routes on the VPN server
> > >>>> pointing to your subnet.
> > >>>>
> > >>>> If that is what you want, you need to setup a gateway on the IPIP
> > >> tunnel mesh.
> > >>>> Or, find someone else who has done that and arrange for some VPN
> > >> between you two.
> > >>>>
> > >>>> Rob
> > >>
> > >> _________________________________________
> > >> 44Net mailing list
> > >> 44Net(a)mailman.ampr.org
> > >> https://mailman.ampr.org/mailman/listinfo/44net
> > >>
> > >
> >
> > - Hessu
> >
> > _________________________________________
> > 44Net mailing list
> > 44Net(a)mailman.ampr.org
> > https://mailman.ampr.org/mailman/listinfo/44net
> >
>
>
>
> ---------- Forwarded message ----------
> From: Nate Sales via 44Net <44net(a)mailman.ampr.org>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Cc: Nate Sales <nate.wsales(a)gmail.com>
> Bcc:
> Date: Fri, 10 May 2019 17:24:47 -0700
> Subject: Re: [44net] VPN Question
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
> Correct. Your approach saves you a lot of work in maintaining custom
> configs. They are a lot of work, if you have a lot of users.
Indeed. We offer OpenVPN connectivity to our local hams (the Netherlands) using certificates
created especially for that. The users get their fixed IP derived from the certificate subject
name (looked up in DNS/hosts) so they also can run services under their own callsign.
There are 220 valid certificates at this time, and always about 20 systems connected plus those
that connect when required.
Those that want to route subnets can get a GRE(6) or L2TP/IPsec tunnel and run BGP over that.
There currently are 34 users of that service, 30 of them are connected.
This mode is also used to provide connectivity to regional clusters of systems that are not yet
connected by radio all over our country.
It requires some one-time setup but at least there is no maintenance when users want to announce
more subnets etc.
Of course more systems like this could be setup in other countries/regions to serve those that
are on dynamic IP, are behind CGNAT, can only use IPv6, etc.
A "cloud" hosted Linux (virtual) machine with a fixed IP is all that you really require, a
service from the ISP to BGP-announce a subnet and route that to you is a good addition.
Alternatively you could use something like a MikroTik, Edgerouter or Juniper instead of the
Linux VM. A little less flexible in some areas but easier to setup and maintain.
Rob
> I cant figure out where to go
> from here. Can anyone point me in the right direction in how to get the
> routes set up for my little subnet?
You can't.
Such a VPN offers you a connection, with an IP, and routes traffic for that IP to you.
You cannot route arbitrary subnets over that because you cannot setup routes on the VPN server
pointing to your subnet.
If that is what you want, you need to setup a gateway on the IPIP tunnel mesh.
Or, find someone else who has done that and arrange for some VPN between you two.
Rob
Hello,
I have obtained the certificates and have openvpn all set up. I am able to
connect, and I see the interface like so:
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 44.139.11.14 peer 44.139.11.13/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::302f:bedc:d77a:c5d6/64 scope link flags 800
valid_lft forever preferred_lft forever
Now I'm a bit stuck. I've consulted a few posts, both
www.qsl.net/kb9mwr/wapr/tcpip/lotw-vpn.html and
www.qsl.net/kb9mwr/wapr/tcpip/oh7lzb.html but I cant figure out where to go
from here. Can anyone point me in the right direction in how to get the
routes set up for my little subnet?
Thanks so much and 73,
-Nate
> While both my node software and my servers are all dual stacked as well,
> the issue with using IPv6 on RADIO (UHF/VHF/HF) is a bit of a challenge
> but do-able.
Of couse "over radio" is not the same thing as "over AX.25"...
These days, radio links on our net-44 network are mostly/all WiFi links and
they would have no issue with IPv6.
AX.25 and IPv6 have other incompatibilities than ARP. The minimum MTU requirement
and the concern about efficiency at low bitrates are other things to worry about.
But what is mainly holding me back to deploy IPv6 now is:
- double effort of network administration for dual-stack
- limited support in our favourite routers (MikroTik)
- lack of immediate need, because we have not run out of IPv4 space and can
still assign usable subnets to everyone who wants them (so no NAT required)
So while I do have IPv6 deployed here at home, I while I don't rule out the
deployment of IPv6 on our radio network, I don't consider it a high-priority
thing.
When doing it, I would get a /48 from our ISP, and then make a 1:1 mapping
between already assigned IPv4 addresses within 44.137.0.0/16 and /64 nets
within that space. So everyone who has a single address gets a corresponding
/64 net and everyone who has a /28 subnets gets a /60 from that, without
requiring any mechanism other than a simple document explaining the mapping.
All places where IPv4 addresses and networks have been configured would get the
corresponding IPv6 address. Probably I would go with encoding callsigns and
service names into the lower 64 bits as proposed by Daniel EA4GPZ.
And for distributing a "list of valid prefixes" amongst those that would like
to be able to classify addresses as "within AMPRnet" or "outside AMPRnet"
(now done by checking for 44.0.0.0/8, which of course does not really work
as Brian Kantor already mentioned), I would propose setting up multihop BGP
peering using private AS numbers between gateway hosts that want to advertise
(and receive) the list of prefixes.
But again, it is not on my list of things to do this year. Keeping everyone
focused on building a working and expanding IPv4 network is more important, IMHO.
Rob
> Now that I know where to look.. PMTU has caused me a lot of headache
> lately. I believe it could be the problem. Sending large packets to
> 44.135.179.28 yields no reply. tracepath does send back need to frag,
> but when TTL expires at amprgw.ucsd.edu. I believe amprgw.ucsd.edu
> should send back need-to-frag for higher TTLs as well.
That is always a bit tricky, often those packets *are* sent back but they
are blocked somewhere closer to the client, and/or the TCP stack of the
system does not process them in a reasonable way.
It is possible to work around that by adjusting the MSS of a TCP SYN
passing the point where outgoing MTU is smaller than incoming MTU
(incidentally something that I invented and implemented in NET in 1995,
but later almost any router and routing software started to support it)
so as a result the TCP segments sent by the endpoints will be smaller and
won't need to be fragmented.
Roger can do that on his own server, e.g. like this:
iptables -t mangle -A INPUT -p tcp --syn -j TCPMSS --set-mss 1400
iptables -t mangle -A OUTPUT -p tcp --syn -j TCPMSS --set-mss 1400
Or on a router/gateway along the path (using FORWARD instead of INPUT/OUTPUT).
However, I'm not convinced that this is the problem as the site works OK
for me over internet. Why wouldn't it work for Google then?
Rob
I have followed Marius' instructions and have my EdgeRouter X working
and passing traffic via 44net. Thank you, Marius!
My issue is this:
I am using 44.2.10.1 for the tunnel, 44.2.10.2 for the computer (a
Raspberry Pi 3), and 44.2.10.3 for JNOS using a point to point tunnel. I
have the following routing in the EdgeRouter:
w6ray@edgerouter:~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 104.49.12.134 0.0.0.0 UG 0 0 0 eth1
44.2.10.0 0.0.0.0 255.255.255.248 U 0 0 0 eth2
44.2.10.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun44
44.2.10.8 44.2.10.9 255.255.255.248 UG 0 0 0 eth3
104.49.12.128 0.0.0.0 255.255.255.248 U 0 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
44.2.10.0/29 eth2 is for the local 44net.
I use the 44.2.10.8/29 on eth3 for the Ubiquity microwave link to the
repeater site where the TNC's and radios are, among other things (DSTAR,
DMR, etc.) I can use the link's LAN 172.16.0.0/16 instead of the
44.2.10.8/29, I just need to figure out how to route traffic. (The link
radios have IP aliases in the 44.2.10.8/29) I do not wish these to be
accessible outside my network.
The 104.49.12.128/29 on eth0 is my public network address.
192.168.1.0/24 on eth0 is so I can access the Edgerouter from the local LAN.
While I would like for JNOS to be accessible outside 44net, it is not
required. I would like to allow our local hams who do not have a TNC
access. I would, however, like to be able to access the Internet from
the Pi (44.2.10.2) so I can use my browser to do searches, and update
the OS via apt.
My question is "How do I accomplish this? Do I have the EdgeRouter X set
up correctly with the proper address(es)?
SJVBBS
w6ray.ampr.org
--
---
If the right side of the brain controls the left side of the body,
then only left-handed people are in their right minds.
_____
, |[][]|
,__| ______| |
,__/__]|| ________ | D8 |
|__!___!!`--'L_______\ |__________|() ___________
"(_)[___]====(_)(_)=| \_(___________)_/__/=(_)===(_)~'
73 de Ray Quinn W6RAY
GMRS - WQTX645
Visalia, CA USA DM06ii
Oops!
I don’t know why all of a sudden my phone picked a different address. Strange. Anyway. Sorry.
Roger
VA7LBB
> On May 8, 2019, at 18:07, Roger <ve7wwd(a)rezgas.com> wrote:
>
> Hi all,
> Just a reminder that Google has already told me where the issue originated. It’s not with content. It’s not with speed. It’s not the time my site has been up. It’s an anomaly between google and me. They just can’t or won’t tell me what that anomaly is. But it has nothing to do with content or anything like that.
>
> Roger.
>
>> On May 7, 2019, at 16:56, David McAnally <david.mcanally(a)gmail.com> wrote:
>>
>> Roger,
>>
>> May I suggest looking at your web site home page load / rendering
>> performance? I tried loading your page in the Google Page speed Insights
>> <https://developers.google.com/speed/pagespeed/insights/> tool. It will
>> not complete loading your URL for analysis, returning the much too common
>> NO_FCP error message. (see their tool's references for details on FCP. I
>> was able to load your URL in the analyze.websiteoptimization.com tool,
>> which shows the page is almost 3MB in size, mostly images and javascript,
>> which may be slowing the page load/rendering. While 3MB may not seem all
>> that much in today's fast networks, home page size and load times have been
>> known to cause crawling index systems to skip the site due their limited
>> budget in time and resources. Poor performance scripting can be an issue
>> too. If your network route to users, or in this case analysis tool, crosses
>> a slower network gateway, the size of your page and content rendering
>> performance could have even more impact. Don't know if improving page
>> performance will make Google indexing happier, but can't hurt to try.
>>
>> At one time I had access to better tools for web site analysis, but I've
>> retired, so I no longer get to play with that stuff.
>>
>> Regards,
>> David M.
>> WD5M
>>
>
>
David,
I thought of that and last week for 4 days I had nothing but a simple index.html (everything else moved out) the google tool did the same thing with a 3kb page. Yet the siteliner.com tool (which is very similar) does not return that error on the large page, and in fact analyses the site very quickly.
I’m starting to suspect this is all Google’s problem.
> On May 7, 2019, at 16:56, David McAnally <david.mcanally(a)gmail.com> wrote:
>
> Roger,
>
> May I suggest looking at your web site home page load / rendering
> performance? I tried loading your page in the Google Page speed Insights
> <https://developers.google.com/speed/pagespeed/insights/> tool. It will
> not complete loading your URL for analysis, returning the much too common
> NO_FCP error message. (see their tool's references for details on FCP. I
> was able to load your URL in the analyze.websiteoptimization.com tool,
> which shows the page is almost 3MB in size, mostly images and javascript,
> which may be slowing the page load/rendering. While 3MB may not seem all
> that much in today's fast networks, home page size and load times have been
> known to cause crawling index systems to skip the site due their limited
> budget in time and resources. Poor performance scripting can be an issue
> too. If your network route to users, or in this case analysis tool, crosses
> a slower network gateway, the size of your page and content rendering
> performance could have even more impact. Don't know if improving page
> performance will make Google indexing happier, but can't hurt to try.
>
> At one time I had access to better tools for web site analysis, but I've
> retired, so I no longer get to play with that stuff.
>
> Regards,
> David M.
> WD5M
>
