Avahi is usually used for service discovery. I want to make a service discoverable from a different subnetwork, could I use avahi to achieve this?
For example, the service host ip is "192.168.1.100" with mask "255.255.255.0", so it's in 192.168.1.X subnetwork. Another host ip is "192.168.2.100" with mask "255.255.255.0". Could I use avahi to let this host discover the previous service host?
Unfortunately, no, it's going to require reconfiguration of whatever device is routing between those two subnets. mDNS uses the multicast addresses 224.0.0.251 for IPv4 and ff02::fb for IPv6. Those are link-local addresses and the data sent to them is typically not routed outside of the current subnet.
There are various options, some may be easier than others depending on what your routing device is.
Multicast Proxying. mdns-repeater is a simple solution that will repeat mDNS requests across interfaces.
Wide Area DNS. Wide-Area DNS-SD could be enabled on the DNS resolver that is service the hosts in those subnets. Avahi could then be configured to publish not the .local domain but to the domain for those subnets.
Multicast Routing. The device routing between those subnets could be configured to route the multicast groups between those two subnets.
mDNS Gateway. There is a draft RFC for implementing a mDNS gateway that sits at the edge of a network segment (typically a router). This is not a simple repeater/reflector, but a gateway that caches service entries and responds to queries from other connected network segments.
Sure you can. It's called a reflector and it's part of the Linux avahi daemon.
Look at "SECTION [REFLECTOR]" of man avahi-daemon.conf on your distribution.
Related
Currently, we have a "HQ" network and a "Branch" network that are completely independent and physically separated in different locations.
This is the current network diagram.
We've been tasked to look at improving security on a fictional network for practice, whilst also adding some DMZs for:
A static website that is accessible by the public.
A web server that is accessible by clients with a VPN.
The Branch and HQ networks should also be linked by a VPN to allow the users in the LAN of the Branch to access resources in the HQ LAN.
My initial ideas are:
Change both HQ and Branch Routers to be Cisco ASA devices and have them as VPN endpoints, removing the now-unnecessary ASA between the HQ Router and Internal Network.
Add the two required DMZs directly from interfaces from the ASA, setting trust zones as required.
My questions are:
Is it a bad idea to replace the Routers with Firewalls? If so, how could I still setup a VPN tunnel between the Branch and HQ easily?
Do I need any other Firewalls (e.g. between the Internal Network and the external Firewall)? If so, why?
How could I configure the network so that one of the DMZs is accessibly only by those on the External Network with a VPN?
Depends on how tight you need to secure your network.
If there is no demand to “hide” router behind firewall the usual way is to place one interface of ASA outside at the same ISP network where router is placed and order IP for it. Other ASA interfaces you could connect to router internal interface (to firewall company traffic) and to DMZ segments.
At this case you could gather requests to your Web server and transfer it to DMZ. And at the same time you could firewall internal company traffic as well.
If you don’t have enough physical interfaces on ASA you could just use switch and do the same with use of switch vlans and ASA sub interfaces (don’t forget to configure switch interfaces in secure way).
I'm working with a supplier to implement Active/Active Site-to-Site IPSec tunnels to two different regions in the same geography. The supplier is using Palo Alto firewalls.
We've managed to establish both tunnels just fine - IKE and IPSec parameters are configured correctly and I can route bidirectionally between Azure and the supplier premises.
Now we're trying to get the route preferences configured so that if the primary tunnel goes down then traffic will automatically be sent over the second tunnel to the second region.
The supplier has requested that we use APIPA addresses for probing whether the tunnels are up are not. No problem, Azure supports APIPA addresses for BGP - but do they respond to ICMP?
What I'm not clear on - despite reading all the MS documentation - is whether the APIPA address configured in the VPN Gateway resource BGP settings is the receiver address or the neighbor address. I'm assuming it's the receiver, and the peer address is configured in the BGP settings of the Local Network Gateway. Correct me if this isn't correct.
The Microsoft documentation says:
Azure VPN Gateway will choose the custom APIPA address if the corresponding local network gateway resource (on-premises network) has an APIPA address as the BGP peer IP.
Does this suggest I can leave the VPN Gateway APIPA empty and Azure will choose one for me? If so, this could be a problem, since the supplier has to specify 2 x /30 address spaces, one for each tunnel and is depending on Azure having a specific address, and the Palo Alto having a specific one. I guess this means I need to configure the address in the VPN first, then configure the peer address in the local gateway?
Aside from that, the supplier only wants to use these addresses for probing by pinging them. I've created BGP configurations in ExpressRoute circuits and can confirm the B-End (Azure) BGP neighbor addresses do respond to ICMP Echo, but I do believe that is only once a successful BGP session has been established.
So my question is, is it possible to specify in an Azure VPN Resource, for example, an APIPA address of 169.254.21.2, a peer address of 169.254.21.1, and without an actual BGP session being established get a ping response from 169.254.21.2. I know it should have TCP 179 open for BGP establishment, but I don't think the Palo Altos can do a port test instead of ping.
I checked with the Azure VPN Product Group team and below is their response on this query:
While Azure VPN gateways allow specific APIPA addresses for each VPN instance, we cannot utilize a prefix-based approach (/30 with fixed allocation). We are looking into allowing more APIPA addresses on the Azure VPN side to workaround this constraint. But we are still in the design phase right now.
At present, the VPN gateway will initiate BGP peering sessions to the on-premises BGP peer IP addresses specified in the local network gateway resources using the private IP addresses on the VPN gateways. This is irrespective of whether the on-premises BGP IP addresses are in the APIPA range or regular private IP addresses.
Reference : https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-bgp-overview#do-azure-vpn-gateways-initiate-bgp-peering-sessions-or-connections
We can have multi APIPA (support in-works) created and configured on the gateway without actually have the BGP peers connected but the requirement for Ping is something that we do not support/recommend.
I have two subnets (A and B) in the same local area network where all IP addresses are static. I just created a DHCP server to solve the problem of IP address conflict.
The problem that there are Hosts that must belong to both Subnets and therefore have two IP addresses.
The router solution is not accepted because if a subnet A station wants to access a station in network B, it must go through the router, but the traffic is very important (SQL queries for statistics) which can cause the flood of the router.
Short: Can I configure my DHCP server to provide two IP addresses to the same Host?
Server operating system: Linux Suse (DHCPD)
This is not a DHCP problem, it's a routing problem.
AFAICT DHCP only lets you specify one IP address per client, but it also lets you push static routes.
You do not need your client to have an IP on both networks, you just need it to know which route to use to reach peers on network A and B (ie direct route in both cases).
See https://gauvain.pocentek.net/docs/dhcpd-push-routes/ to specify static routes for DHCP.
Currently my LB has a IPv4 frontend address and one backend pool with 5 VMs with IPv4 private addresses.
We would like to add IPv6 support to our Service Fabric cluster. I found this article: https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-ipv6-overview and I see a lot of "Currently not supported" texts.
The IPv6 address is assigned to the LB, but I cannot make rules:
Failed to save load balancer rule 'rulename'. Error: Frontend ipConfiguration '/subscriptions/...' referring to PublicIp with PublicIpAddressVersion 'IPv6' does not match with PrivateIpAddressVersion 'IPv4' referenced by backend ipConfiguration '/subscriptions/...' for the load balancer rule '/subscriptions/...'.
When I try to add a new backend pool, I get this message:
One basic SKU load balancer can only be associated with one virtual machine scale set at any point of time
Questions:
When can we expect the feature to have multiple LBs before one VMSS?
Is it possible to add IPv6 frontend without adding IPv6 to the backend (NAT64?)?
Is it possible to add IPv6 addresses to an existing VM scale set without recreating it?
Not sure I am understanding you exactly, It seems that some limitations are in that article.
For your questions:
I guess you mean mapping multiple LB frontends to one backend pool. If so, the same frontend protocol and port are reused across multiple frontends since each rule must produce a flow with a unique combination of destination IP address and destination port. You can get more details about multiple frontend configurations with LB.
It is not possible. The IP version of the frontend IP address must match the IP version of the target network IP configuration.
NAT64 (translation of IPv6 to IPv4) is not supported.
It is not possible, A VM Scale Set is essentially a group of load balanced VMs. There are a few differences between VM and A Vmss, you can refer to this. Also, If a network interface has a private IPv6 address assigned to it, you must add (attach) it to a VM when you create the VM. Read the network interface constraints.
You may not upgrade existing VMs to use IPv6 addresses. You must
deploy new VMs.
I have a question regarding destination determination of DNS lookups when a machine is connected to multi network interfaces (Linux).
Intro:
I am developing a Linux box which is connected to 2 (or more) networks.
Each Network interface is connected to a different network (ISP) and receives (DHCP) different IP / Default Gateway and 2 DNS servers.
The box runs different network applications (clients) which are bounded to a specific interface.
For example:
Application A connects to a server via network 1 (interface 1).
Application B connects to a server via network 2 (interface 2).
I can use source based routing to control the destination interface for each Application.
(In Linux with routing policy - ip rule/ ip route / etc…).
My question is regarding DNS lookups:
Linux share one resolv.conf file, both networks (1,2) DNS server are maintained in this file.
When an application uses the standard getaddrinfo() function, it uses Linux default resolving mechanism (which goes through the reolv.conf file).
This means that Application B can send its DNS queries to a DNS server which is related to network 1.
I have access to the code, I can do it manually and send a DNS query directly to a specific DNS server from my application, but this is not the preferred option.
Is there standard ways (code/or configuration) to cause DNS lookups from Application A choose network 1 DNS server and Application B choose network 2 DNS server?
Thanks
No. You'll need to perform DNS resolution in a different manner than depending on the IP stack.