I haven't been able to solve this problem for a few days, I've followed millions of tutorials online but I couldn't find anything about it.
I have an EC2 instance that has as private ip: 172.31.27.40.
I have only one VPC (the default one, with 3 subnets).
This is my SG:
On prem I have ip address (public): 1.2.3.4.
I created a customer-gateway (with on-prem public ip), a virtual-private-gateway (to which I attached the vpc) and the site-to-site connection.
My 2 tunnels are UP , in Static-Routes I added 192.168.0.0/24 (my on prem subnet).
I am using the aws-updown.sh script in the ipsec configuration.
My ipsec config:
conn Tunnel1
auto=start
left=%defaultroute
leftid=1.2.3.4
right=(Outside IP address Tunn1)
type=tunnel
leftauth=psk
rightauth=psk
keyexchange=ikev1
ike=aes128-sha1-modp1024
ikelifetime=8h
esp=aes128-sha1-modp1024
lifetime=1h
keyingtries=%forever
leftsubnet=192.168.0.0/24
rightsubnet=172.31.0.0/16
dpddelay=10s
dpdtimeout=30s
dpdaction=restart
## Please note the following line assumes you only have two tunnels in your Strongswan configuration file. This "mark" value must be unique and may need to be changed based on other entries in your configuration file.
mark=499
## Uncomment the following line to utilize the script from the "Automated Tunnel Healhcheck and Failover" section. Ensure that the integer after "-m" matches the "mark" value above, and <VPC CIDR> is replaced with the CIDR of your VPC
## (e.g. 192.168.1.0/24)
leftupdown="/usr/local/sbin/ipsec-notify.sh -ln Tunnel1 -ll *******/30 -lr ******/30 -m 499 -r 172.31.0.0/16"
This is my route table:
From EC2:
[root#ip-***** ec2-user]# ping 192.168.0.58
PING 192.168.0.58 (192.168.0.58) 56(84) bytes of data.
64 bytes from 192.168.0.58: icmp_seq=1 ttl=64 time=7.82 ms
64 bytes from 192.168.0.58: icmp_seq=2 ttl=64 time=7.84 ms
64 bytes from 192.168.0.58: icmp_seq=3 ttl=64 time=7.76 ms
64 bytes from 192.168.0.58: icmp_seq=4 ttl=64 time=10.8 ms
From On prem:
root#****:/home/utente# ping 172.31.27.40
PING 172.31.27.40 (172.31.27.40) 56(84) bytes of data.
From 169.254.**** icmp_seq=1 Destination Host Unreachable
From 169.254.**** icmp_seq=2 Destination Host Unreachable
From 169.254.**** icmp_seq=3 Destination Host Unreachable
From 169.254.**** icmp_seq=4 Destination Host Unreachable
Can you help me?
Related
I was trying to ping some websites from my laptop but every time i got response from my wifi router.
But When I Connect My Cellphone with the same router ping and other thing works fine.
By pinging Google (from my laptop) I got the following output:
PING google.com.ib-wrb304n.setup.in (192.168.2.1) 56(84) bytes of data.
64 bytes from _gateway (192.168.2.1): icmp_seq=1 ttl=64 time=3.10 ms
64 bytes from _gateway (192.168.2.1): icmp_seq=2 ttl=64 time=8.29 ms
64 bytes from _gateway (192.168.2.1): icmp_seq=3 ttl=64 time=11.9 ms
64 bytes from _gateway (192.168.2.1): icmp_seq=4 ttl=64 time=8.54 ms
64 bytes from _gateway (192.168.2.1): icmp_seq=5 ttl=64 time=8.56 ms
64 bytes from _gateway (192.168.2.1): icmp_seq=6 ttl=64 time=7.82 ms
64 bytes from _gateway (192.168.2.1): icmp_seq=7 ttl=64 time=8.52 ms
64 bytes from _gateway (192.168.2.1): icmp_seq=8 ttl=64 time=8.42 ms
64 bytes from _gateway (192.168.2.1): icmp_seq=9 ttl=64 time=8.45 ms
also all apt requests failing due to this.
but if i connect my laptop to my cellphone's wifi it works fine.
i've tried reinstalling my os also by downloading fresh iso files.
But Nothing Seems To Work
It looks like it has no GW, so it arps for Google, the router replies with it's MAC via proxy ARP, and then to the pings. Check your config, arp cache and ISP.
Basically, if you clear the arp cache and then ping google, only the GW ARP entry should re-appear. (first close your browser and all other connections, of course) EXAMPLE:
Mac_3.2.57$sudo arp -d -a
10.0.0.14 (10.0.0.14) deleted
10.0.0.229 (10.0.0.229) deleted
10.0.0.255 (10.0.0.255) deleted
224.0.0.251 (224.0.0.251) deleted
239.255.255.250 (239.255.255.250) deleted
Mac_3.2.57$arp -a
Mac_3.2.57$ping google.com
PING google.com (172.217.165.142): 56 data bytes
64 bytes from 172.217.165.142: icmp_seq=0 ttl=57 time=20.942 ms
64 bytes from 172.217.165.142: icmp_seq=1 ttl=57 time=21.516 ms
64 bytes from 172.217.165.142: icmp_seq=2 ttl=57 time=20.725 ms
64 bytes from 172.217.165.142: icmp_seq=3 ttl=57 time=19.750 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 19.750/20.733/21.516/0.637 ms
Mac_3.2.57$arp -a
? (10.0.0.1) at 5c:76:95:eb:28:43 on en0 ifscope [ethernet]
Mac_3.2.57$
I was doing az login from WSL of my windows machine. Then it gives an error:
Please ensure you have network connection. Error detail: HTTPSConnectionPool(host='login.microsoftonline.com', port=443): Max retries exceeded with url: /common/oauth2/token (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f401d135630>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
I hope this is a DNS issue.
So I checked /etc/resolv.conf of WSL:
# This file was automatically generated by WSL. To stop automatic generation of this file, remove this line.
nameserver 192.168.1.1
nameserver fcc0:0:0:ffff::1
nameserver fcc0:0:0:ffff::2
192.168.1.1 is the default gateway.
There are the results of some commands I tried:
$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=128 time=0.351 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=128 time=0.888 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=128 time=0.883 ms
$ dig 192.168.1.1
; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> 192.168.1.1
;; global options: +cmd
;; connection timed out; no servers could be reached
$ nslookup 192.168.1.1
;; connection timed out; no servers could be reached
These commands also give an output that indicates an issue.
Ping google.com
dig google.com
All these commands( or its alternatives) work from the Windows command prompt works correctly.
I found a workaround here:
https://askubuntu.com/questions/91543/apt-get-update-fails-to-fetch-files-temporary-failure-resolving-error
It says that I should add the followinng line to /etc/resolv.conf. If I try it like this, it works.
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver fcc0:0:0:ffff::1
nameserver fcc0:0:0:ffff::2
After this, the ping google.com and dig google.com works fine. But I can see that the nameserver it uses to resolve is 8.8.8.8.
If I connect to VPN, it adds our own nameservers to /etc/resolv.conf and after that, there is no problem in resolving the URLs. Once the VPN is disconnected, the issue arises again.
Note:
There were no issues like this before.
Last day we changed our router in order to use a new ISP's connection and after that, the issue occurs.
Other machines in the same network don't have this issue.
Why this occurs and How can I properly fix this issue of WSL?
Why only one machine in our network can ping, but can't dig to the default gateway?
Update:
I can see that there are two entries that are marked as default in routing table:
$ ip route show table all | grep default
none default via 192.168.0.1 dev wifi0 proto unspec metric 0
none default via 192.168.1.1 dev eth6 proto unspec metric 0
There is a computer with Ubuntu 18.04 it is located behind the NAT router and receives the address in the subnet 192.168.1.0/24. For example 192.168.1.11
I connect from this computer to the VPN server using the IPSec IKEv2 protocol but neither systemctl start strongswan nor ipsec start do not raise the connection, I'm can connect in only one way:
sudo charon-cmd --cert ca-cert.pem --host vpn_domain_or_IP --identity your_username
After connecting I get the address from the NAT subnet on the VPN server 10.10.10.0/24 for example 10.10.10.11 VPN works and all traffic goes through the tunnel. But the connection to the local network completely disappears, requests from subnet 192.168.1.0/24 to address 192.168.1.11 and from my computer to any of the subnet addresses 192.168.1.0/24 do not pass
Output ip a:
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 18:d6:c7:14:ff:04 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.11/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
valid_lft 562sec preferred_lft 562sec
15: ipsec0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN group default qlen 500
link/none
inet 10.10.10.11/32 scope global ipsec0
valid_lft forever preferred_lft forever
inet6 fe80::5b2:78:42:d7/64 scope link stable-privacy
valid_lft forever preferred_lft forever
Ping
:~# ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data.
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=0.071 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=0.070 ms
64 bytes from 192.168.1.11: icmp_seq=3 ttl=64 time=0.069 ms
64 bytes from 192.168.1.11: icmp_seq=4 ttl=64 time=0.072 ms
64 bytes from 192.168.1.11: icmp_seq=5 ttl=64 time=0.067 ms
^C
--- 192.168.1.11 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4075ms
rtt min/avg/max/mdev = 0.067/0.069/0.072/0.010 ms
:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
^C
--- 192.168.1.1 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5105ms
All configurations are identical to this resource.
The referred resource has leftsubnet=0.0.0.0/0 set. That causes the VPN connection to default to route everything through the VPN. So simplest is if You can change that. I also want to do this (so add all public-ranges in that list and omit private ranges, maybe besides a special private range to reach the servers LAN). Otherwise You have to manage Your local routing on connecting client "manually". (If both sides use strongwan it should be possible to narrow it on eighter side without breaking the SA completely, but not certain whether specifying multiple subnets works with IKEv1 between strongswan client and server or whether You would need to define multiple SAs then.)
Regarding "only way to establish connection"... I'm wondering whether that means You really have the example confiuration (ike2-rw in ipsec.conf) and started daemon and it is not working - but the example is working on server. I had problems with the Strongswan on Ubuntu 18.04 server side (the VPN gateway), it was connecting but connection came not up. The client I did not try. But I found the Ubuntu 18.04 package is broken (or was back then, a few monmth ago) and upgraded my Ubuntu. With 19.04 it works like a charm. (What is Your journal for the strongswan service saying and syslog - or better the /var/log/charon.log when You try to bring up the client as per documentation?)
When I enter localhost:8000 in my Chrome browser, it redirects to localhost and gives me the ol' "This site can’t be reached - localhost refused to connect."
Going to localhost:8000/wp-admin and localhost:8000/services both work fine.
I am using Docker-Wordpress-Compose.
Here is my hosts file:
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
Here is what I get when I ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.042 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.013 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.038 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.057 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.049 ms
And when I ping localhost:8000
ping: cannot resolve localhost:8000: Unknown host
First do a netstat -pluton to show your open ports, if you don't see your 8000 port maybe it's because you didn't open it with run -d --link database:database -p 8000:8080 wordpress, did you try with localhost:8000/wordpress ? And check in your apache2.conf if you're allowed to connect.
Question first: Does anyone know why scp won't resolve the dns name wheezy to the ip address 192.168.164.144 while ping does?
Explanation & Details second:
While on OS Mavericks I could scp files from my terminal to my VMWare Fusion Debian instance just fine. I just had to make sure that the ip address and machine name (wheezy) were in both the Debian /etc/hosts file and in the /etc/hosts file of my mac.
However after upgrading to Yosemite I can't scp files to my virtual host using the domain name. I CAN scp files to the virtual machine if I specify the ip address. So this works:
scp test_file.txt dan#192.168.165.144:~/
but this does not:
scp test_file.txt dan#wheezy:~/
This boggles my mind because the host "wheezy" pings just fine:
BASHdan#DanRauxa ~ >>ping wheezy
PING wheezy (192.168.165.144): 56 data bytes
64 bytes from 192.168.165.144: icmp_seq=0 ttl=64 time=0.335 ms
64 bytes from 192.168.165.144: icmp_seq=1 ttl=64 time=0.337 ms
64 bytes from 192.168.165.144: icmp_seq=2 ttl=64 time=0.290 ms
^C
--- wheezy ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.290/0.321/0.337/0.022 ms
and my /etc/hosts file is actually identical on both the Yosemite and Wheezy machine:
127.0.0.1 localhost
192.168.165.1 DanRauxa
192.168.165.144 wheezy
127.0.0.1 drupal-7-31.local
127.0.0.1 drupal8devprep.local
Does anyone know why scp won't resolve the dns name wheezy to the ip address 192.168.164.144 while ping does?
Many thanks.
-d-
Check your ~/.ssh/config to see if there is a wheezy host in there.
Also run the scp in verbose mode:
scp -v test_file.txt dan#wheezy:~/.
Might give you more information on where the failure is happening.