I have a network problem that I can't solve, I have a server at hetzner and a server at OVH, I'm trying to use some OVH ip on my hetzner server and some Hetzner ip on my OVH server, because I need flexibility in my network.
My VMs are on proxmox, I created a vxlan between the 2 servers and I bridge the vxlan in the vmbr0 interface of proxmox on one side and it works but ovh and hetzner informed me that I was sending packet with wrong mac address, so I don't know what to do.
I'm really not an expert in computer networking.
Thank you in advance to all those who can help me.
VxLAN offers a lot of flexibility, however it might not be the best answer in this case. You may be better off using VPN tunnels between both cloud environments. That is, assuming you can have multiple VMs within the tenant on those providers, have them point their default gateways towards a VM within your control, and use that VM as a firewall/VPN concentrator. From there you can establish a S2S VPN between the cloud environments, and can NAT the traffic from your provider's WAN IP address to the appropriate host, whether locally, or at the remote environment.
If you must have L2 connectivity between your cloud environments, I can speak from experience only in a Juniper environment, and in that case we would place a vMX VM behind a vSRX VM. The vMX VM would act as the EVPN/VXLAN VTEP, and your VMs would set this as their default gateway. The vSRX would establish IPSEC S2S tunnels, through which data-center interconnect (DCI) traffic would flow. L2 traffic would flow through the vMX, where it would be encapsulated in a vxlan tunnel, which would route through the SRX, which would then encapsulate this in an encrypted IPSEC tunnel, before sending to the other data center. Details of this might be a little too complex for a stack exchange answer though.
Hope this helps point you in the right direction!
Related
My company has an on-premise network which is opened by OpenVPN server.
In the ordinary scenarios, I used to connect to that server very easily.
However, when I tried to that server from the OCI compute instance which I connected by SSH from my laptop, there exist some problems. As soon as I try to connect VPN server, my SSH connection is closed.
IMHO, this may occurred because VPN connection changes network information and so my SSH connection might be lost.
I tried to look around to find out how to connect to VPN from OCI, but almost everything was using IPSec protocol which Oracle provided, others were about builting OpenVPN Server on the OCI instance.
I'm very novice for the network structure. So, please give me some hint to resolve this problem.
Thanks,
I get the following:
You have Ubuntu 18.04 VM on a Public Subnet in OCI
You have OpenVPN Server running on On-Prem.
You would like to access your On-Prem from Ubuntu VM on OCI.
If I understood it correctly, the best way is to set up IPSec VPN. It isn't that hard if you hit right steps. At the high level, you will be doing the following steps. I have used IKEv1 in my attempts in the past.
OCI:
Create a DRG
Attach/Associate it to your VCN
Create a CPE (Customer Premise Equipment) and mark the IP Address of OpenVPN server to it.
Create an IPSec Connection on the DRG. It will create two Tunnels with its own Security Information.
Set up Routing on associated subnet (i.e., one that hosts Ubuntu VM) so traffic associated to On-Prem CIDR are routed to DRG.
On-Prem:
Create necessary configuration to create the Tunnels upto OCI (Using the configuration information from previous steps such as VPN Server IP Addresses and Shared Secrets)
Set up Routing so that the Traffic destined for OCI CIDR ranges are sent to associated Tunnel Interface
This ensures that you can create multiple VMs on the OCI Subnet all of which can connect to your On-Prem infrastructure. OCI Documentation has sufficient information in setting up this VPN Connection.
Alternatively if your only requirement is to establish connectivity between Ubuntu VM on OCI to OpenVPN server On-Prem, you might use any VPN Client software and set it up. This doesn't need any of the configuration steps mentioned above.
Worker nodes in private subnets have private IP addresses only (they do not have public IP addresses). They can only be accessed by other resources inside the VCN. Oracle recommends using bastion hosts to control external access (such as SSH) to worker nodes in private subnets. You can learn more on using SSH to connect through a bastion host here - https://docs.cloud.oracle.com/en-us/iaas/Content/Resources/Assets/whitepapers/bastion-hosts.pdf
So a little background of what I'm trying to accomplish. I'm basically trying to setup a Windows File Server using GCP VM Windows Instance. I have the VM setup and I have created a VPN connection between our office network and to the GCP VM network.
Now I'm trying to communicate between the two different subnets and I have to admit I'm kinda lost.
My office subnet is 192.168.72.0/24 and my GCP IP is 10.123.0.0 with my server being at 10.123.0.2
If I understand networking correctly I need to setup a route between 192.168.72.0 to 10.123.0.2? Or do I just need to create a firewall rule?
I'm using a SonicWall Firewall to establish the VPN connection to the GCP network.
I think I've been working at this too long for one day. I'm steaping away for a bit.
Thanks in advance.
If you set up a Site to Site, you should not need to include a route, you will if you setup a Tunnel Interface. But to me, it sounds like you just need to do a site to site. I dont think the tunnel will come up without the correct subnets, but just verify that the tunnel is up and then I would setup a packet monitor to see what route the traffic is taking when you try to ping from 192.168.72.0/24 to IP is 10.123.0.0.
Please bear with me as my background is development and not sysadmin. Networking is something I'm learning as I go and thus why I'm writing here :)
A couple of months ago I started the process of designing the network structure of our cloud. After a couple of exchange here, I settled for having a project that will host a VPN Tunnel to the on-premise resources and some other projects that will host our products once they are moved from the on-premises servers.
All is good and I managed to set things up.
Now, one of the projects is dedicated to "storage": that means, for us, databases, buckets for statis data to be accessed around , etc.
I created a first mySQL database (2nd gen) to start testing and noticed that the only option available to access the SQL databases from Internal IPs was with the "parent project" subnetwork.
I realised that SQL Engine create a subnetwork dedicated for just that. It's written in the documentation as well, silly me.
No problem, I tear it down, enable Private Service Connection, create an allocated IP range in the VPC management and set it to export routes.
Then I went back to the SQL Engine a created a new database. As expected the new one had the IP assigned to the allocated IP range set up previously.
Now, I expected every peered network to be able to see the SQL subnetwork as well but apparently not. Again, RDFM you silly goose. It was written there as well.
I activated a bronze support subscription with GCP to have some guidance but what I got was a repeated "create a vpn tunnel between the two projects" which left me a little disappointed as the concept of Peered VPC is so good.
But anyway, let's do that then.
I created a tunnel pointing to a gateway on the project that will have K8s clusters and vice-versa.
The dashboard tells me that the tunnel are established but apparently there is a problem with the bgp settings because they are hanging on "Waiting for peer" on both side, since forever.
At this point I'm looking for anything related to BGP but all I can find is how it works in theory, what it is used for, which are the ASM numbers reserved etc etc.
I really need someone to point out the obvious and tell me what I fucked up here, so:
This is the VPN tunnel on the projects that hosts the databases:
And this is the VPN tunnel on the project where the products will be deployed, that need to access the databases.
Any help is greatly appreciated!
Regarding the BGP status "Waiting for peer" in your VPN tunnel, I believe this is due to the configured Cloud Router BGP IP and BGP peer IP. When configuring, the Cloud Router BGP IP address of tunnel1 is going to be the BGP Peer IP address for tunnel2, and the BGP Peer IP address for tunnel1 is going to be the Router BGP IP address of tunnel2.
Referring to your scenario, the IP address for stage-tunnel-to-cerberus should be:
Router BGP IP address: 169.254.1.2
and,
BGP Peer IP address: 169.254.1.1
This should put your VPN tunnels BGP session status in "BGP established".
You can't achieve what you want by VPN or by VPC Peering. In fact there is a rule in VPC which avoid peering transitivity described in the restriction part
Only directly peered networks can communicate. Transitive peering is not supported. In other words, if VPC network N1 is peered with N2 and N3, but N2 and N3 are not directly connected, VPC network N2 cannot communicate with VPC network N3 over VPC Network Peering.
Now, take what you want to achieve. When you use a Cloud SQL private IP, you create a peering between your VPC and the VPC of the Cloud SQL. And you have another peering (or VPN tunnel) for the SQL engine.
SQL Engine -> Peering -> Project -> Peering -> Cloud SQL
Like this you can't.
But you can use the shared VPC. Create a shared VPC, add your 2 projects in it, create a common subnet for SQL Engine and the Cloud SQL peering. That should work.
But, be careful. All VPC features aren't available with shared VPC. For example, serverless VPC connector aren't yet compliant with it.
Hope this help!
The original setup in the OP question should work, i.e.
Network 1 <--- (VPN) ---> Network 2 <--- (Peered) ---> CloudSQL network
(the network and the peering is created by GCP)
Then resource in Network 1 is able to access a MySQL instance created in the CloudSQLz network.
I want to connect to a Cisco Anyconnect VPN (which I believe does NOT act as a proxy -- my IP address doesn't change when connecting to this VPN).
However I wish to hide my true IP to the Cisco Anyconnect server I'm connecting to.
Can I connect to another VPN service like TunnelBear first, then connect to the Cisco Anyconnect server, and be sure the Cisco Anyconnect server is seeing my TunnelBear proxy IP and not my real IP?
The scenario you are describing should be possible, using the technology you described. I would assume the sequence of events would follow:
Initiate OpenVPN connection
Initiate Cisco VPN connection
However, keep in mind that you may need to install a client to access the Cisco VPN. These clients tend to interact with and potentially manipulate your operating system's network configuration, this makes sense when you consider that these applications are built to re-route your network traffic. These clients would most likely have the ability to see your VPN configuration.
A possible workaround to the issues outlined above, regarding the local client being able to recognize your network configuration: one might configure their host's entire gateway (router or perhaps virtual machine host) to route traffic through the primary VPN.
You should keep in mind the resource usage and computation power required in order to maintain each VPN's security and (possibly) compression layers.
Even if the second VPN connection is established, I wouldn't expect quality performance, and multiple compression layers could be suboptimal.
I was wondering that how application like skype ( a popular chat client ) works in local network with one router, How it can listen on particular port?
for example:=
In one network A and B are two machines running skype , gateway of both is G1,
now how A and B will have same IP on internet that is of G1, but how can they ensure that they are listening on different ports? How can they ask to router G1 for unique port.
I want to make a simple text chat server on linux. How can I have connections between two different computers in two different networks?
Solution to your problem is to have a forwarding server somewhere in the net.
Different programs use different means to connect to each other. But every chat server, including Skype, has a server, which forwards data or information about subnet IP/port availability.
There are two types of clients: "listening" clients and "passive" ones. Listening clients have direct access to Internet via router port forwarding, and "passive" ones have to use additional tricks to get their hands on external data, line external servers or additional ports to listen.
The point is, not clients connect to each other, but they connect to a server, which then connects back to them to verify they are available, and, if at least one of them is not firewalled, direct another on to connect to the first one, excludint itself from further communication. And if both are firewalled, then is has to forward their messages through itself.
Host Discovery
Manual discovery, client A knowns who client B is
Discovery through broadcast UDP which is used by lot of games for LAN play. A client sends out a packet to the broadcast address for their subnet. The peers can choose to pick up this broadcast and respond. The downside is that this is limited to the current subnet. The more general INADDR_BROADCAST (255.255.255.255) works for all subnets on the local-link, but it cannot be routed, so won't work over internet (this is what DHCP auto-configuration uses).
Discovery through a central (Rendezvous) server. Each individual client knows the address of the server, and the latter informs them about each other. This technique is used by IRC, Voip, IMs and by most 'peer-to-peer' networks.
Communication
After the initial discovery is done you want to be able to talk to eachother. On the internet this can get tricky. Most people nowadays have their own router and sit behind a NAT, so direct connections are impossible.
Using a Rendezvous server, you can possibly talk to each other using the server itself. client A tells the server what to say, and it in turn tells client B, since both clients have an outbound connection to the server.
It is possible for the clients to talk to each other without the server proxying. This requires either DMZ, port forwarding or UPnP. DMZ will basically forward all incoming connections on all the ports to a given local IP. Port forwarding only forwards certain ports to local IPs. UPnP is a bit more advanced, the client requests that the router temporarily forwards a port to it, and you tell the other client via the rendezvous server where to connect.
Chatting app implementation
The easiest solution to your problem is most likely to use a central server, which is known by all the clients, that proxies host discovery and possibly the communication between the clients. If you want the clients to communicate directly, you can just proxy host discovery, and then let either DMz, manual port forwarding or UPnP do the rest.
Another solution would be to just have direct communication through NAT traversal techniques discussed above, and do manual host discovery.
Yet another solution would be to use a public webserver and 'abuse' its ability to insert content to chat with each other.
You need a central UDP Rendezvous Server.
After the initial connection from the client to the server the UDP clients can be redirected to talk to eachother directly even if firewalled.
The trick is to open an UDP connection from the inside.
Check out Real-Time Media Flow Protocol and how they use it.
Check out UDP Hole Punching
alt text http://labs.adobe.com/technologies/stratus/images/p2pvideo_250x215.jpg
Traditional NAT servers replace the source address and port with the address and a random port number of the external interface of the NAT server. This works well for simple protocols such as HTTP and SMTP, but it can create problems for more complex protocols that require multiple response ports on the external interface of the NAT server. NAT servers also aren’t aware of information stored in the data portion of the application layer header without the help of NAT editors and similar software fixes.
Windows XP’s answer to these problems is NAT Traversal, which can automatically allow the UPnP-enabled NAT client application to communicate with a UPnP NAT device. NAT Traversal provides methods to allow the UPnP client to learn the public IP address of the NAT server and to negotiate dynamically assigned port mappings for UPnP NAT client applications.
NAT Traversal features can be built into any hardware device or software application. Applications that commonly cause troubles for NAT devices but work well when UPnP-enabled include the following:
Multiplayer Internet games
Audio and video communications
Terminal Services clients and servers
Peer-to-peer file sharing applications
When these applications are UPnP-enabled, access through the Windows XP ICS allows them to work seamlessly.
Unless A and B are actually "listening" to the responses to outgoing requests, your router will need to be cofigured to forward the relevant port numbers to the relevant hosts. This isn't something that you can request in the code, it's something you need to configure on the router itself.