target-ip = 10.10.0.40 target-port = 22 host-port = 2022 -tcp
Host TCP port 2022 -> 10.10.0.40:22
simics> enable-real-time-mode
Port forwarding forwards traffic on TCP and UDP ports between the simulated network and the real network. It also allows forwarding DNS queries from the simulated network to the real network. Port forwarding can be used with any kind of IP network on the host, it is not limited to Ethernet networks.
Port forwarding is probably the easiest way to access the real network for simple TCP or UDP connectivity, for example, telnet or FTP usage. Port forwarding is easy to set up. Simics does not need administrative privileges to run port forwarding, and neither the simulation host nor any other host needs to be configured in any way.
Port forwarding is managed by a service node connected to an Ethernet link. It is the service node that listens for traffic on both the real and simulated networks and forwards it to the other side. All port forwarding commands except connect-real-network therefore take as argument an Ethernet link with a connected service node.
There are really four distinct parts to Simics's port forwarding solution: forwarding of specific ports from the real network to the simulated network, forwarding of specific ports from the simulated network to the real network, NAPT from the simulated network to the real network, and forwarding of DNS queries to the real network.
There is also a convenience command named connect-real-network that automatically sets up NAPT for outgoing traffic, forwarding of DNS queries to the real network, and incoming port forwarding for some common services. If there is no Ethernet link object, one is created and set up.
The list-port-forwarding-setup command describes the current port forwarding setup: it will list all incoming and outgoing ports, as well as the NAPT and DNS forwarding status.
The connect-real-network command is a convenience command that sets up NAPT for outgoing traffic, enables forwarding of DNS queries to the real network, and opens incoming ports for FTP, HTTP and telnet to a simulated machine. This is an easy way to get inbound and outbound access for common services on a simulated machine.
The command requires a target-ip argument that specifies the IP address of the simulated machine that should be targeted by the incoming traffic. If there are multiple simulated machines, connect-real-network can be run once for each machine. Simics will select different ports on the simulation host for the incoming services for each simulated machine, and the selected ports are printed in the Simics console.
The connect-real-network command does not require an Ethernet link as argument, unless there is more than one in the simulation. If there is no Ethernet link or service node, they will be created automatically.
The connect-real-network allows us to set up all connections that are needed for most simple real network uses with one simple command. We can start from the checkpoint prepared in section 4.1, and then run the connect-real-network command with the IP address 10.10.0.40, which is the default address of QSP-x86:
simics> connect-real-network 10.10.0.40 No Ethernet link found, created default_eth_switch0. Connected board.mb.sb.eth_slot to default_eth_switch0 Created instantiated 'service_node_comp' component 'default_service_node0' Connecting 'default_service_node0' to 'default_eth_switch0' as 10.10.0.1 NAPT enabled with gateway 10.10.0.1/24 on link default_eth_switch0.link. NAPT enabled with gateway fe80::2220:20ff:fe20:2000/64 on link default_eth_switch0.link. Host TCP port 4021 -> 10.10.0.40:21 Host TCP port 4022 -> 10.10.0.40:22 Host TCP port 4023 -> 10.10.0.40:23 Host TCP port 4080 -> 10.10.0.40:80 Real DNS enabled at 10.10.0.1/24 on link default_eth_switch0.link. Real DNS enabled at fe80::2220:20ff:fe20:2000/64 on link default_eth_switch0.link.
The output shows that an ethernet_switch and a service_node_comp components have been automatically created and connected to the simulated machine. NAPT, DNS forwarding, and incoming port forwarding for FTP, HTTP and telnet have also been enabled.
Now start the simulation. Since we gave the service node the IP address 10.10.0.1, QSP-x86 should be configured with 10.10.0.1 as default gateway:
~# route add default gw 10.10.0.1
It should now be possible to telnet from the simulated machine to hosts on the real network. In this case, we telnet to a Solaris machine with IP address 10.0.0.240; replace this address with any host answering to telnet on the network:
~# telnet 10.0.0.240 Trying 10.0.0.240... Connected to 10.0.0.240. Escape character is '^]'. SunOS 5.9 login: joe Password: Sun Microsystems Inc. SunOS 5.9 Generic May 2002 $ exit Connection closed by foreign host. ~#
QSP-x86 can be configured to use the service node as
DNS server and use it to look up real DNS names. To do that, add the
line nameserver 10.10.0.1 in the file
/etc/resolv.conf on the simulated machine:
~# echo nameserver 10.10.0.1 > /etc/resolv.conf
It should now be possible to look up the addresses of real hosts on the simulated machine, for example, https://gnu.org. QSP-x86 does not have the tools to perform DNS lookups. Instead, verify that DNS works by connecting to a real server by name:
~# telnet gnu.org 80 GET / <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <title>Server error!</title> [...] Connection closed by foreign host. ~#
FTP, HTTP and telnet servers running on the simulated machine should also be accessible. QSP-x86 runs both a telnet and a HTTP server. Just use port 4023 and 4080 instead of 23 and 80. The exact ports of the host these services are mapped to varies if the default ports are already in use. Look at the output from the connect-real-network above for the port numbers to use.
The connect-real-network-port-in command sets up port forwarding from a port on the host machine to a specific port on a simulated machine. It takes three required arguments: ethernet-link, target-ip and target-port, that specify the Ethernet link, IP address and port the traffic should be forwarded to.
An IP address and preferred port can be selected for incoming traffic on the simulation host using the host-ip and host-port arguments. If these arguments are not provided, Simics will select a port automatically and print it on the Simics console, and receive all IPv4 traffic (i.e., IP 0.0.0.0) from that port. In order to forward multicast traffic, specify that multicast address (e.g., specify 239.255.255.253 to forward IPv4 SLP traffic).
The connect-real-network-port-in command can also take the flags -tcp and -udp, which specify whether forwarding is set up for a TCP or a UDP port. If neither is provided, forwarding will be set up for both the TCP and UDP ports.
The service node acts as a proxy for incoming traffic, so to initiate a connection to a specific port on the simulated machine, the real machine should contact the corresponding open port on the simulation host. The simulation host is not a gateway to the simulated network.
Any UDP packets sent to a port on the simulation host are forwarded to the specified port and IP address on the simulated network. For the simulated machine to be able to return UDP packets to the real network, a separate forwarding rule must be set up using the connect-real-network-port-out command.
Any TCP connections to the port on the simulation host are forwarded to the specified port and IP address on the simulated network. Since TCP connections are two-ways, once a connection has been established, data can be sent in both directions.
QSP-x86 runs sshd on port 22. We can now set up a port forwarding rule that allows us to access the ssh service from the real network. Start from the checkpoint, create an Ethernet link and service node, connect the simulated machine to the Ethernet link and run the connect-real-network-port-in command like this:
simics> load-module eth-links simics> new-ethernet-switch switch0 Created instantiated 'ethernet_switch' component 'switch0' simics> new-service-node-comp sn0 Created instantiated 'service_node_comp' component 'sn0' simics> sn0.connect-to-link switch0 10.10.0.1 Adding host info for IP 10.10.0.1: simics0.network.sim MAC: 20:20:20:20:20:00 simics> connect board.mb.sb.eth_slot switch0.device1 simics> connect-real-network-port-in ethernet-link = switch0
QSP-x86 uses the IP address 10.10.0.40 and the ssh service runs on TCP port 22. We use port 2022 on the simulation host, but any free port can be used. The last command slows down QSP-x86 to avoid time-outs.
Start the simulation, then start a ssh from a real host to the ssh service port of the simulated machine by connecting to port 2022 of the simulation host. In our case, we do the ssh on the simulation host itself; replace localhost with the IP address of the simulation host if running ssh from another machine:
host:~$ ssh -p 2022 -l root localhost The authenticity of host '[localhost]:2022 ([127.0.0.1]:2022)' can't be established. ECDSA key fingerprint is 62:7e:eb:4d:6d:cb:ae:0f:a0:a9:44:cc:0d:59:ce:52. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '[localhost]:2022' (ECDSA) to the list of known hosts. Last login: Mon Jan 18 10:34:08 2016 ~# ls / bin boot dev disk2 etc home host lib lib64 lost+found media mnt proc run sbin sys tmp usr var www ~# exit logout Connection to localhost closed.
The connect-real-network-port-out command sets up port forwarding from a port on a service node to a specific port on a host on the real network. It takes four required arguments: service-node-port ethernet-link, target-ip and target-port, that specify the port on the service node that will forward traffic to the target, the Ethernet link the service node is connected to, and the real IP address and port to which the traffic should be forwarded.
The command can optionally take the flags -tcp and -udp, to specify whether the forwarding should be set up for a TCP or UDP port. If neither is provided, forwarding will be set up for both the TCP and UDP port.
The service node acts as a proxy for outgoing traffic, so to initiate a connection to a port on a host on the real network, the simulated machine should connect to the corresponding mapped port on the service node. The service node is not a gateway to the real network.
Any UDP packets sent to a port on the service node are forwarded to the specified port and IP address on the real network. For the real host to be able to return UDP packets to the simulated network, a separate forwarding rule must be set up using the connect-real-network-port-in command.
Any TCP connections to the port on the service node are forwarded to the specified port and IP address on the real network. Since TCP connections are two-ways, once a connection has been established data can be sent in both directions.
By setting up forwarding from a port on a service node to port 22 of a host on the real network, it should be possible to ssh to the real host by connecting to the port on the service node from QSP-x86. We can start from the checkpoint we prepared in section 4.1, and create an Ethernet link and a service node, connect the simulated machine to the Ethernet link and run the connect-real-network-port-out command. Here we use a host on the real network with IP address 10.0.0.240, replace it with the IP address of a real host on the network:
simics> load-module eth-links simics> new-ethernet-switch switch0 Created instantiated 'ethernet_switch' component 'switch0' simics> new-service-node-comp sn0 Created instantiated 'service_node_comp' component 'sn0' simics> sn0.connect-to-link switch0 10.10.0.1 Adding host info for IP 10.10.0.1: simics0.network.sim MAC: 20:20:20:20:20:00 simics> connect board.mb.sb.eth_slot switch0.device1 simics> connect-real-network-port-out service-node-port = 2222
Now start the simulation. We used the IP address 10.10.0.1 and the port 2222 for the service node, so we should be able to ssh to the real host by connecting to port 2222 of 10.10.0.1 from QSP-x86:
~# ssh 10.10.0.1 -p 2222 The authenticity of host '[10.10.0.1]:2222 ([10.10.0.1]:2222)' can't be establis hed. ECDSA key fingerprint is 39:a4:cb:1c:54:4b:bd:86:9f:d1:1b:6d:a6:43:e9:f4. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '[10.10.0.1]:2222' (ECDSA) to the list of known hosts . 10.10.0.1's password: Last login: Thu May 19 09:59:33 2016 from 127.0.0.1 host:~$ ls / bin dev home lib64 media opt root sbin sys usr boot etc lib lost+found mnt proc run srv tmp var
The connect-real-network-napt command sets up NAPT (network address port translation, also known as just NAT or network address translation) between the simulated network and the real network. With NAPT enabled, the service node will act as a gateway on the simulated network and automatically mediate TCP connections to the real network.
The connect-real-network-napt only has one required argument, ethernet-link, that specifies the Ethernet link that should be connected to the real network.
The simulated machines must be configured to use the service node as gateway for the real network, so that it is able to capture the outgoing traffic. The simulated machines will then be able to access hosts on the real network using their real IP addresses. By combining NAPT with DNS forwarding, described in section DNS Forwarding, the real DNS names of hosts on the real network can be used as well.
The NAPT setup is not specific to a simulated machine, so connect-real-network-napt needs only to run once for each Ethernet link, and all simulated machines on the link get outbound access.
Since NAPT only allows new TCP connections to be opened from the simulated network to the real network, and the FTP protocol need to open new ports when transferring files, passive mode FTP should be used when connecting to an FTP server on a host on the real network from a simulated machine. An alternative is to use the FTP server implemented in the Simics service-node and avoid the need to connect to a real network.
To try NAPT, we can start from the checkpoint we prepared in section 4.1, create an Ethernet link and service node, connect the simulated machine to the Ethernet link and run the connect-real-network-napt command like this:
simics> load-module eth-links simics> new-ethernet-switch switch0 Created instantiated 'ethernet_switch' component 'switch0' simics> new-service-node-comp sn0 Created instantiated 'service_node_comp' component 'sn0' simics> sn0.connect-to-link switch0 10.10.0.1 Adding host info for IP 10.10.0.1: simics0.network.sim MAC: 20:20:20:20:20:00 simics> connect board.mb.sb.eth_slot switch0.device1 simics> connect-real-network-napt ethernet-link = switch0 NAPT enabled with gateway 10.10.0.1 on link switch0.link NAPT enabled with gateway fe80::2220:20ff:fe20:2000/16 on link switch0.link simics> enable-real-time-mode
The simulated machine should be configured to use the service node as its default gateway:
~# route add default gw 10.10.0.1
The enable-real-dns and disable-real-dns commands of the service node enable and disable forwarding of DNS requests to the real network by a service node. This allows simulated machines to look up names and IP addresses of hosts on the real network, using the service node as DNS server.
To try DNS forwarding, we can start from the checkpoint we prepared in section 4.1, and create an Ethernet link and a service node, connect the simulated machine to the Ethernet link and run the enable-real-dns command like this:
simics> load-module eth-links simics> new-ethernet-switch switch0 Created instantiated 'ethernet_switch' component 'switch0' simics> new-service-node-comp sn0 Created instantiated 'service_node_comp' component 'sn0' simics> sn0.connect-to-link switch0 10.10.0.1 Adding host info for IP 10.10.0.1: simics0.network.sim MAC: 20:20:20:20:20:00 simics> connect board.mb.sb.eth_slot switch0.device1 simics> sn0.enable-real-dns Real DNS enabled simics> enable-real-time-mode
To tell QSP-x86 to use the service node as DNS
server, the line nameserver 10.10.0.1 is needed in the file
/etc/resolv.conf:
~# echo nameserver 10.10.0.1 > /etc/resolv.conf