Pings ok but nothing else
-
Hi Gertjan, Thanks for getting back to me. I did follow that document and its all connected. However when I attempt to do anything other than ping or traceroute, like going to an ipv6 test site it fails the test. If I attempt to get gmail the page won't load.
I know its got to be something at my end I just have exhausted my knowledgebase.
Mark
-
Fetching a https page form pfSEnse using IPv6 works :
curl https://www.google.com -6 -v -o file
?
-
Doesn't seem to do it either (just like the client).
curl https://www.google.com -6 -v -o test
- Rebuilt URL to: https://www.google.com/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 2607:f8b0:400b:808::2004... - TCP_NODELAY set
- Connected to www.google.com (2607:f8b0:400b:808::2004) port 443 (#0)
- ALPN, offering h2
- ALPN, offering http/1.1
- Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
- successfully set certificate verify locations:
- CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: none - TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data] - TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
0 0 0 0 0 0 0 0 --:--:-- 0:01:19 --:--:-- 0* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.google.com:443
0 0 0 0 0 0 0 0 --:--:-- 0:01:19 --:--:-- 0 - Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.google.com:443
and yet
ping6 google.com
PING6(56=40+8+8 bytes) myipv6 --> 2607:f8b0:400b:808::200e
16 bytes from 2607:f8b0:400b:808::200e, icmp_seq=0 hlim=58 time=10.821 ms
16 bytes from 2607:f8b0:400b:808::200e, icmp_seq=1 hlim=58 time=15.937 ms
16 bytes from 2607:f8b0:400b:808::200e, icmp_seq=2 hlim=58 time=10.721 ms
16 bytes from 2607:f8b0:400b:808::200e, icmp_seq=3 hlim=58 time=10.719 ms
16 bytes from 2607:f8b0:400b:808::200e, icmp_seq=4 hlim=58 time=10.852 ms
16 bytes from 2607:f8b0:400b:808::200e, icmp_seq=5 hlim=58 time=10.723 ms
16 bytes from 2607:f8b0:400b:808::200e, icmp_seq=6 hlim=58 time=10.793 ms
16 bytes from 2607:f8b0:400b:808::200e, icmp_seq=7 hlim=58 time=10.469 msmtu is at 1280 but I've tried it at other recommended settings.
- Rebuilt URL to: https://www.google.com/
-
@mark-b said in Pings ok but nothing else:
mtu is at 1280 but I've tried it at other recommended settings.
What is the MTU on the he.net side ?
-
Its the same. 1280. I've tried different values but I read to start low and move up.
I have a friend using ipv6 and he can ping my hosts but I can't reach his. Kind of odd but he might have firewall rules in place.
Tried rebooting pfsense this morning but nothing changed.
The firewall for the vlan that has ipv6 i have allow all to everywhere rule and nothing in outbound nat.
I also removed ipv4 on the vlan and that didn't change anything for ivp6. I lost connectivity to everything on ipv4.
I've read lots about tls errors on ipv6 but nothing really definitive in their conclusions. Most just shut off ipv6.
-
In your Firewall rules, make sure you have the relevant Allow All rules in place to allow you to talk out:
Also, just double check that on the Interface you have assigned to the HE GIF, you are allowing ICMP through too.
As for the MTU Size, I've got mine set to 1472 (my PPPoE is set to 1492) and this works fine for me. Make sure, again, that the interface assigned to the HE GIF, has the same MTU as configured within tunnelbroker:
IPV6 over IPV4 (which is effectively what is happening with this tunnel) we only need to work out the IPV4 overhead (20 bytes) so this is why my MTU is set to 1472. I'm not sure if you would also need to consider the overhead for 802.1q (VLAN) which is 4 bytes, so you may need to up it to 24 bytes overhead.
-
@mark-b said in Pings ok but nothing else:
The firewall for the vlan that has ipv6 i have allow all to everywhere rule and nothing in outbound nat.
Post them... Pretty sure that "SSL_ERROR_SYSCALL" is just a generic sort of error.. Like could not even open the connection.. Which would point to say a rule that is only allowing icmp. Which would explain why pings and traceroutes work.. As to you reaching your friends - does he allow it?
How about a simple sniff on your client as you try your curl test.. Do you see the syn and syn,ack come back?
curl https://www.google.com -6 -v * Rebuilt URL to: https://www.google.com/ * Trying 2607:f8b0:4001:c16::93... * TCP_NODELAY set * Connected to www.google.com (2607:f8b0:4001:c16::93) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 * ALPN, server accepted to use h2 * Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com * start date: Oct 2 07:29:00 2018 GMT * expire date: Dec 25 07:29:00 2018 GMT * subjectAltName: host "www.google.com" matched cert's "www.google.com" * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x832e48) > GET / HTTP/1.1 > Host: www.google.com > User-Agent: curl/7.52.1 > Accept: */* > * Connection state changed (MAX_CONCURRENT_STREAMS updated)! < HTTP/2 200 < date: Mon, 22 Oct 2018 13:14:15 GMT < expires: -1 < cache-control: private, max-age=0 < content-type: text/html; charset=ISO-8859-1 < p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info." < server: gws < x-xss-protection: 1; mode=block < x-frame-options: SAMEORIGIN < set-cookie: 1P_JAR=2018-10-22-13; expires=Wed, 21-Nov-2018 13:14:15 GMT; path=/; domain=.google.com < set-cookie: NID=141=dc0I-nZrv3S-M9-A6LQN2Q2kwZ4vzSh4y9N3qHUEDoWUK8yRdgkJWddhdmkMzSnilbQiMfVyRkqxlGgUcMjdweeYEOtuA6RrTXZ0d44f8gxmHjFLCtVPa014xHoc7UKY; expires=Tue, 23-Apr-2019 13:14:15 GMT; path=/; domain=.google.com; HttpOnly < alt-svc: quic=":443"; ma=2592000; v="44,43,39,35" < accept-ranges: none < vary: Accept-Encoding < <!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="en"><head><meta content="Search the world's information, including webpages, images, videos and more. Google has many special features to help you find exactl <SNIPPED REST of PAGE>
Have used HE for years - its rock solid stable - running 2.4.4 pfsense.
-
On the vlan I have
On the tunnel interface I have
I have played with different mtu settings and always made sure they were the same at both ends
and
-
0_1540221523636_tcpdump-ipv6.txt
This is looking for traffic on the lan interface at the router.
Keep getting spam error trying to post this, I hope it works with upload file.
I know its not he.net or the equipment. It has to be something I have misconfigured. No more hair to pull out.
-
Have you ended up figuring this one out? I’m having similar issues.