I am trying to use a GNS3 network as input data to Microsoft Sentinel. My GNS3 server with GNS3 network is running on a virtual Linux machine, so I can monitor it with Syslog connector successfully. However I am unable to detect anything from the GNS3 network. Any idead how to solve this? I would be grategul for any answer.
Related
Sorry for the newbie question.
I just installed Vmare workstation and created a windows server 2012 virtual machine(Set up remote desktop on the server 2012)
The virtual machine is hosted on the below Ip.
The virtual machine Ip.
Adapter settings
Nat Settings
When remote desktop from 192.168.2.120(virtual machine host) to 192.168.88.128 the remote desktop work fine , but when trying from a different PC on the same network(192.168.2.107) to remote desktop to (192.168.88.128) then remote desktop can be access.
The problem in your case is the adapter option you are using in VMWare for your Windows Server. Rather than using a NAT adapter use the Bridged option.
Your answer ends above but if you need a bit insight of your problem then you can read the further part. The NAT IP of Windows server which is the guest machine (192.168.88.128) is reachable from the host machine(192.168.2.120) just because your host machine is internally connected (via a virtual switch) to the guest machine. If you check the network adapters in your host machine then you will find an adapter which will have an IP (192.168.88.1). Your host machine is communicating with your guest machine via this adapter.
The NAT option hides your virtual machine from the physical network. If you want to reach your machine then you have to configure some routing table entries to route packets (heading towards your VM) to your host machine and then again in your host machine you have to write a static route so that the packet received on 192.168.2.120 is forwarded to 192.168.88.0/24
I am running code talking to GigE Vision / gen<i>cam cameras inside a docker container. The real deployment will run on Windows host (unfortunately). The cameras respond to broadcasted UDP discovery packets to port 3965 (wireshark dissects those as GVCP protocol, DISCOVER_CMD):
Obviously, UDP packets can't cross network bridges, though --network=host helped on Linux: the camera was discovered.
On Windows host, the --network=host had no effect and the discover packet (sent from within the container) never makes it to the LAN. The Windows Defender firewall is off and there is no other firewall/antivirus/whatever active.
I can also run camera discovery program in Windows (not in the hosted container) and it works.
Any idea what could be wrong? I was googling for things like "docker egress UDP windows" with no useful result.
Probably already to late but in case someone else comes along.
Docker --network=host wont work in windows and therefore has no effect as stated here:
This can be found in the Docker Documentation
The host networking driver only works on Linux hosts, and is not
supported on Docker Desktop for Mac, Docker Desktop for Windows, or
Docker EE for Windows Server.
I am trying to connect my BACNET client which has been containerized and the BACNET server which is running on the host machine. I am using Docker for Windows on Windows 10 (host machine) with Linux containers.
I have tried the following:
a. Publishing the ports 47808 for the client container with the run command.
b. Running the container with network=host, to access services of localhost.
c. Tried specifying the gateway IP as the server's IP address with run command.
d. Running the container in the same subnet as my server
e. Running the container with the host IP specified and the ports published.
My bacnet server, taken from https://sourceforge.net/projects/bacnet/ always connects to the DockerNAT, 10.0.75.1? Any idea why does this happens? The server application is not a container but an executable file.
Server IP:10.0.75.1 (dockerNAT)
Client container running on host machine.
From a quick google:
For Windows containers this component is not used and containers and
their ports are only accessible via the NATed IP address.
With respect to BACnet, this is going to put you in a world of hurt. You will have to use BACnet BBMD with NAT support in your container to achieve this, and your BACnet Client will have to register as a BACnet Foreign Device. The BACnet Stack at SourceForge does seem to have some NAT support (the code seems to be there but I have never tested it in its original form).
So what you are seeing is 'expected', but your solution is going to require that you become much more familiar with BACnet BBMDs than you ever want to be. Read the BACnet specification carefully. Good luck.
I have a clean install of Openstack Pike on Ubuntu 16.04 server with OvS bridge. When using iptables_hybrid as the firewall driver, I have no problem sending SCTP packets to VMs from the external network. However, when using the native openvswitch firewall driver, SCTP packets never arrive at the VM but TCP/UDP works fine.
I have tried adding SCTP in the policy groups and I have also created ports with security disabled but nothing helped.
Neutron is configured with DVR and redundant DHCP, otherwise it's pretty standard configuration based on the install guide for OvS with self-service networks. I can provide log and config files if needed.
Any ideas what might be causing this? Iptables has a huge performance impact on the network and I would like to go back to openvswitch firewall.
I want to telnet to check firewall opened from Solace to a server.
Telnet command is not available in Solace.
How do you do a telnet from Solace appliance?
The answer depends on which VRF you want to check. There are two VRFs on the solace appliance: management and msg-backbone.
The msg-backbone VRF is mainly for the data plane where all messages get brokered. This is on specialized hardware, and there is no support for the regular Linux networking stack. Telnet naturally is not supported. You can, however, test ping connectivity through the CLI: ping msg-backbone:<ip-address>.
The management VRF, as the name suggests is for management traffic. This is on a typical ethernet NIC and is on the Linux networking stack. SolOS base is a CentOS-7 image. So the answer can be found in https://serverfault.com/questions/788934/check-if-remote-host-port-is-open-cant-use-gnu-netcat-nor-nmap-rhel-7.