I am trying to have host with multiple interface at Mininet and ping from h1-h2 (topology can be seen from the attached figure). If I have flow rules at S1 to send packets over 3rd output port, directly to the S2 switch it works fine. But if i try to change the packet to follow 2nd output port of S1 which is connected to h3, the packet cannot go through S2.
I can ping from h1 to h3, or h1 to h4. Similarly, from h2-h3 and h2-h4. But not h1-h2 if i want to use h3 and h4 at the route. I assign routes for each hosts as:
h3.cmd("sudo ip route add 192.168.10.1 dev h3-eth1")
Also changed configuration of hosts as:
h3.cmd("sudo echo 1 > /proc/sys/net/ipv4/ip_forward")
h3.cmd("echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp")
I configured IP address of each interface and checked them after starting Mininet.
My simple topology:
What is the problem here I am facing? Does anybody have an idea?
Related
I'm using GCP like in the following schema:
TCP balancer -> backend-service -> MIG(my app) with auto scaling.
"My app" accepts commands on a TCP port (A) and sends notifications on another TCP port(B) for subscriber.
I'm running my tests against TCP LB's IP - my tests connect to port B on a startup(i.e. one of instances of "my app") and also my tests make a connection to port A for each test.
i.e. I've faced with a case when port A and port B are terminated/connected to different hosts.
I am not sure how to circumvent this case.
I have mitigated the issue using --session-affinity=CLIENT_IP for backend-services configuration, I.e. all connections from one IP are directed to the same target.
I understand that 0.0.0.0/0 this means that i'm allowed whatever my IP is to connect to this instance(server).
I'm trying to modify my GCP instance firewall rule, to allow my IP only to access this instance, I'm accessing it via ssh as it's an ubuntu server. So I've to specify in the rule some adress in the form of 0.0.0.0/0 where my public IP is not in this format.
I don't understand the following
what is /0 means ?
How to generate an IP that match this format ?
Should I be using my public IP or another kind of IP ?
Have a look at this Wiki Article on CIDR notation.
https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_notation
In GCP (and possibly elsewhere), the CIDR range of 0.0.0.0/0 is used to donate any address at all.
If you want to restrict traffic to your Compute Engine instance at the IP level, then:
Determine your own IP address ... for example 1.2.3.4
Change the firewall rule to allow only traffic from 1.2.3.4/32
Given that an IP address (ipV4) is 32 bits then when we suffix a CIDR range with /32 we are saying the whole IP address must match.
1) Get the external ip from where you going to ssh with typing ( what is my ip ) in any browser , copy that ip
2) create firewall rule and use that external ip e.g 35.34.36.37/32 for port 22 (ssh ) with "apply to all instance" option set
3) If you are using putty for ssh then make sure to export the ssh key to the instance
After following all above step if should work
The best recommendation I would give is to open a case on issuetracker where your project will inspect closely by GCP team if you dont have any support package orthherwise open a case directly from your project.
The reason behind this recommendation is because some needs to inspect your project for solving your problem
I tired to provide my IP4/32 it still wasn't working. But i found a solution for this problem.
solution
First go to IAP
Copy this IP 35.235.240.0/20 under Preparing your project for IAP TCP forwarding
This range contains all IP addresses that IAP uses for TCP forwarding
Paste the copied IP inside the IP source of your firewall rule.
Go to What_Is_My_IP and copy your IPv4
Add your copied IP to the IP source range inside your firewall rule
save, and start your ssh connection to the VM
I do UDP hole punching using the following method: I have a lobby server L, and two clients A and B behind a (shared) NAT.
Now, A and B are running on the same machine. They both send a datagram to server L.
Server L tells both A and B the IP+PORT of the other.
Note that the IPs of A and B that the server sees are identical, but the ports are different, as expected.
Then A and B send a datagram to each other, using the server provided addr+port.
Yet, their datagrams to each other never arrive.
My question: does UDP hole punching work if both clients are on the same machine? What if they are just on the same LAN, behind the same NAT?
NOTE: I tried to lower the strictness of my router, but Archer C7 does not seem to have a selection for Cone/Symmetric/Asymmetric unfortunately. I did switch off Stateful Packet Inspection.
UPDATE: When I try sending punch datagrams, I do see this come by over the network device:
ICMP dest unrch (port)
UPDATE: stunclient output:
$ stunclient --mode full stunserver.stunprotocol.org
Binding test: success
Local address: 10.0.1.2:49703
Mapped address: 209.161.250.218:49703
Behavior test: success
Nat behavior: Endpoint Independent Mapping
Filtering test: success
Nat filtering: Address and Port Dependent Filtering
Solution: It turns out ipv6 has got it's own firewall which I didn't know and it filtered out 80 and 443! Thanks so much Nicholas Pipitone!
I'm having difficulties to get apache to accept ipv6 connections (everything perfect on ipv4). Results from ready.chair6.net:
What I tested/tried:
Disabling firewall doesn't change the result
Getting apache to listen on all interfaces or specifically the ipv6 interface doesnt change the result
Executing 'curl https://v6.ident.me/' correctly sends me back my ipv6 address
Netstat tells me that both the ipv4 AND ipv6 address are listening for connections on 80 and 443
I'm really stuck here, what else can I do?
The MX record error means it's having a problem getting the IP address from the DNS servers.
Solution: Try dig +short AAAA $hostname and dig +short MX $hostname, with $hostname being your URL. If you don't see an IPv6 IP in the terminal, then you don't have DNS fully setup. If you just recently setup your URL, then wait a day for caches to be updated. If it's been a while, talk to who you bought the domain name from / who's responsible for making your URL point to your IP.
Note: MX is only for mail. If you don't want incoming mail / that's not what the problem is, then that test is testing something it doesn't have to test, and you can ignore it.
More possibilities: Is the hostname on line 4 the same as the host name on the second to last line? Try pinging that IPv6 address from line 4 on a different computer (Not on the same private network); what do you get?
If you get a response, try nmaping the IPv6 on another computer to see if port 80 is open to the public.
-If the nmap fails then try checking your port forwarding settings if you're behind a NAT. If you're not behind the NAT then something might be blocking the request in-between their computer and your computer (Very unlikely); you can try telnet'ing to port 80 remotely and see if you're getting the requests - because then it's just an apache issue.
-If nmap succeeded, then what do you get? Send an HTTP request over command line from the another computer and see if you get a response.
If pinging doesn't work, then you're just not connected to the internet (o.O), idk how to help with that. If pinging the IPv6 works but pinging the URL doesn't, then dig must not be showing anything and it's the DNS as mentioned previously. If dig does show something in that case, then I'm lost.
I was looking for an answer on my question on google and also here, but a didn't find a proper answer.
So here is the context:
I have a software running on some server (without firewall) in one subnet.
There is another software running on some PC in a different subnet.
Both subnets are connected to a gateway server. All computers are running CentOS or RHEL.
On the gateway server, there is a firewall, preventing multicast traffic from leaving the one subnet and allow clients from outside to connect to computers inside this subnet. Therefore xinetd is used. The computer from outside needs to send a packet to a specific port, the computer on the inside answers to another specific port depending on the sender. So there is no need for the gateway to keep track of sender-receiver relations. It just needs to forward UDP on specific ports to specific computers from one subnet to another.
So I added one service in /etc/services (for one direction):
udp-gateway 6000/udp
And created the according configuration file in /etc/xinetd.d/gateway like:
service udp-gateway
{
disable = no
socket_type = dgram
protocol = udp
wait = no
user = root
redirect = 192.168.1.1 6000 #Server inside the 192.168.1.0 subnet
}
Now the problem is, that the server doesn't open an UDP-port to listen on ('netstat -nulp' says). When I change the protocol to TCP and the socket_type to stream, it works. But I need this for UDP.
Is it possible that this is not possible for UDP? Or is netstat just not showing the ports? Or is my xinetd-configuration missing something?
Thanks in advance, every hint is appreciated.
Benny
redirect = 192.168.1.1 6000 #Server inside the 192.168.1.0 subnet
from the man page of xinetd:
redirect
Allows a tcp service to be redirected to another host.
This means usage of redirect for udp is not possible. And I don't see any other way to do this with xinetd.