What is the purpose of the "destination address" for a TAP/TUN device?
Pytun lets you easily set parameters of a tap/tun device:
tun = TapTunDevice(name='mytun')
tun.addr = '10.66.66.1'
tun.dstaddr = '10.66.66.2'
tun.netmask = '255.255.255.0'
tun.up()
Doing this will result in a device configured as such:
$ ifconfig mytun
mytun: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.66.66.1 netmask 255.255.255.0 destination 10.66.66.2
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
I understand that the system now has a virtual interface with IP 10.66.66.1. And it's presumable that in this scenario, the TUN device would be "connected" to a (e.g. VPN gateway) device whose IP address is 10.66.66.2.
But what purpose specifically, does it serve for the kernel to know that this is a "point-to-point" interface, and the IP address of the destination? Does it impact routing in some way that simply configuring the route table would not achieve?
Setting the dstaddr property results in a SIOCSIFDSTADDR ioctl.
The netdevice(7) man page simply says:
SIOCGIFDSTADDR, SIOCSIFDSTADDR
Get or set the destination address of a point-to-point device
using ifr_dstaddr. For compatibility, only AF_INET addresses
are accepted or returned. Setting the destination address is
a privileged operation.
I don't care about all this I want to configure my interface
You don't need to set a destination address. If you want to configure 10.66.66.1/24 on the interface, you can do:
tun = TapTunDevice(name='mytun')
tun.addr = '10.66.66.1'
tun.netmask = '255.255.255.0'
tun.up()
This interface only connects two hosts, so you don't actually need a whole /24. You can only say that 10.66.66.1 is connected to 10.66.66.2 (10.66.66.1 peer 10.66.66.2):
tun = TapTunDevice(name='mytun')
tun.addr = '10.66.66.1'
tun.dstaddr = '10.66.66.2'
tun.netmask = '255.255.255.255'
tun.up()
In this setup, the two IP addresses do not need to be in the same range at all.
Alternatively, you could use a /31, RFC3021:
tun = TapTunDevice(name='mytun')
tun.addr = '10.66.66.2'
tun.dstaddr = '10.66.66.3'
tun.netmask = '255.255.255.254'
tun.up()
Notice, how I had to change the IP addresses in order for them to be in the same /31.
What is a POINTOPOINT device?
The POINTOPOINT means that on this interface there is no Layer 2 addressing (no MAC address) on this interface:
no ARP requests (IPv4);
no NDP requests (IPv6);
the neighbour table is useless for this interface (ip neighbour);
in routing table entries for this interface the via directive is ignored;
packets on this interface are always send to the same (only) next-hop.
Examples of POINTOPOINT devices
PPP interfaces: There is not Layer 2 address for PPP as this type of interface connects a single host to another host (hence the name "point-to-point protocol")
TUN interfaces: They are IP only interfaces without a Layer 2.
POINTOPOINT means that this is a point-to-point interface (surprise!) which means that there can be only one peer connected at the other-side of the interface: you have one neighbor on this interface and you do not need to use ARP/NDP for mapping IP address to link-layer address (and you do not have link layer address at all).
In contrast, an Ethernet device is not a point-to-point interface because multiple hosts can be directly reacheable via this interface. When you send an IP packet to such a device, the network stack has to find a layer 2 identifier (using ARP, NDP) for the intended IP address and send the message to this link-layer address.
Say this, is your routing table (in Ethernet):
default via 192.0.2.1 dev eth0 proto static metric 100
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.2 metric 100
Multiple hosts can be directly connected to you via the eth0 interface. If you want to send a packet to 198.51.100.1, this route is selected:
default via 192.0.2.1 dev eth0 proto static metric 100
which means that among all your neighbors on the eth0 device, you have to send the packet to 192.0.2.1. In order to to that, your network stack has to find the MAC address of 192.0.2.1 by using ARP.
On a POINTOPOINT device, there is always only one neighbor so you don't need to do ARP, you only need to send the packet.
TUN and PPP interfaces are POINTOPOINT devices. Ethernet, Ethernet TAP devices and Wifi interfaces are not POINTOPOINT.
What is the destination (peer) address?
Usually the IP configuration of an interface is in the form: 192.0.2.1/24. This means that the ip address of this interface is 192.0.2.1 and that all IP in the 192.0.2.0/24 subnet are directly reachable via this interface: this adds a routing rule 192.0.2.0/24 dev tun0.
The Linux kernel supports another type of configuration when the local IP address and the peer address does not belong to the same IP subnet: 192.0.2.1 peer 198.51.100.1. This means that the IP address of this interface is 192.0.2.1 and that the IP address of the peer is 198.51.100.1: this adds a routing rule 198.51.100.1 dev tun0. A more general form can be used: 192.0.2.1 peer 198.51.100.1/24.
$ ip address show tun0
14: tun0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 192.0.2.1 198.51.100.1/24 scope global tun0
valid_lft forever preferred_lft forever
The dstaddr parameter (and the SIOCSIFDSTADDR) can be used to set such as destination address.
This is useful if you don't want to allocate a common subnet for the two peers. You don't have to use a special destination address with point to point interface. You could use a standard IP subnet. Or you could allocate a /31. Using the destination address/peer configuration, you can avoid allocating a subnet for this point-to-point link.
What is the relation between the peer/destination address and POINTOPOINT devices?
These are independant. You don't have top set a destination address on a POINTOPOINT interface. You can set a destination address on a POINTOPOINT and you can do it on a normal one as well.
However, using a peer destination address is especially/mostly useful for POINTOPOINT interfaces.
If you add an interface with
inet 10.66.66.1 netmask 255.255.255.0
No matter if you create it as point to point, or not- a new routing entry will be added to the kernel for 10.66.66.1/24 with destination of the new interface.
So I don't think that there is a difference there.
Related
I have a Cisco ASA 5506-X running version 9.9(2). I recently upgraded my internet to gigabit speeds (in reality about 750 - 850 Mbps). However, my ASA was only allowing throughput of about 200Mbps. I thought that the ASA would allow throughput up to 750Mbps.
Troubleshooting steps:
Reset ASA and setup basic config.
Tested internet speed and received somewhere near 200Mbps.
Disabled FirePower service and tested speed again to get near 300Mbps
Connected PC directly to cable modem and was able to get speeds of 800Mbps - 850Mbps (three attempts).
Re-connected ASA and still get only 300Mbps (maybe 310).
Can you help me figure out why I'm not getting better throughput?
Show Version:
Cisco Adaptive Security Appliance Software Version 9.9(2)36
Firepower Extensible Operating System Version 2.3(1.122)
Device Manager Version 7.16(1)150
Compiled on Wed 12-Dec-18 16:53 PST by builders
System image file is "disk0:/asa992-36-lfbff-k8.SPA"
Config file at boot was "startup-config"
ciscoasa up 16 secs
Hardware: ASA5506, 4096 MB RAM, CPU Atom C2000 series 1250 MHz, 1 CPU (4 cores)
Internal ATA Compact Flash, 8000MB
BIOS Flash M25P64 # 0xfed01000, 16384KB
Encryption hardware device : Cisco ASA Crypto on-board accelerator (revision 0x1)
Number of accelerators: 1
1: Ext: GigabitEthernet1/1 : address is b0c5.3cfa.25d8, irq 255
2: Ext: GigabitEthernet1/2 : address is b0c5.3cfa.25d9, irq 255
3: Ext: GigabitEthernet1/3 : address is b0c5.3cfa.25da, irq 255
4: Ext: GigabitEthernet1/4 : address is b0c5.3cfa.25db, irq 255
5: Ext: GigabitEthernet1/5 : address is b0c5.3cfa.25dc, irq 255
6: Ext: GigabitEthernet1/6 : address is b0c5.3cfa.25dd, irq 255
7: Ext: GigabitEthernet1/7 : address is b0c5.3cfa.25de, irq 255
8: Ext: GigabitEthernet1/8 : address is b0c5.3cfa.25df, irq 255
9: Int: Internal-Data1/1 : address is b0c5.3cfa.25d7, irq 255
10: Int: Internal-Data1/2 : address is 0000.0001.0002, irq 0
11: Int: Internal-Control1/1 : address is 0000.0001.0001, irq 0
12: Int: Internal-Data1/3 : address is 0000.0001.0003, irq 0
13: Ext: Management1/1 : address is b0c5.3cfa.25d7, irq 0
14: Int: Internal-Data1/4 : address is 0000.0100.0001, irq 0
Licensed features for this platform:
Maximum Physical Interfaces : Unlimited perpetual
Maximum VLANs : 30 perpetual
Inside Hosts : Unlimited perpetual
Failover : Active/Standby perpetual
Encryption-DES : Enabled perpetual
Encryption-3DES-AES : Enabled perpetual
Carrier : Disabled perpetual
AnyConnect Premium Peers : 4 perpetual
AnyConnect Essentials : Disabled perpetual
Other VPN Peers : 50 perpetual
Total VPN Peers : 50 perpetual
AnyConnect for Mobile : Disabled perpetual
AnyConnect for Cisco VPN Phone : Disabled perpetual
Advanced Endpoint Assessment : Disabled perpetual
Shared License : Disabled perpetual
Total TLS Proxy Sessions : 160 perpetual
Botnet Traffic Filter : Disabled perpetual
Cluster : Disabled perpetual
This platform has an ASA 5506 Security Plus license.
Serial Number: JXXXXXXXXXX
Running Permanent Activation Key: 0x1A1A1A1A 0x2B2B2B2B 0x3C3C3C3C 0x4D4D4D4D 0x5E5E5E5E
Configuration register is 0x1
Image type : Release
Key Version : A
Configuration has not been modified since last system restart.
Config
ASA Version 9.9(2)36
!
hostname ciscoasa
enable password xxxxxxxxxxxxxxxxxxxxxxx pbkdf2
passwd xxxxxxxxxxxx. encrypted
names
!
interface GigabitEthernet1/1
nameif outside
security-level 0
ip address dhcp setroute
!
interface GigabitEthernet1/2
nameif inside
security-level 100
ip address 172.16.254.1 255.255.255.0
!
interface GigabitEthernet1/3
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet1/4
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet1/5
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet1/6
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet1/7
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet1/8
shutdown
no nameif
no security-level
no ip address
!
interface Management1/1
management-only
shutdown
no nameif
no security-level
no ip address
!
ftp mode passive
access-list INBOUND extended permit icmp any any echo-reply
pager lines 24
mtu outside 1500
mtu inside 1500
no failover
no monitor-interface service-module
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
no arp permit-nonconnected
arp rate-limit 16384
!
nat (inside,outside) after-auto source dynamic any interface
access-group INBOUND in interface outside
timeout xlate 3:00:00
timeout pat-xlate 0:00:30
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 sctp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
timeout conn-holddown 0:00:15
timeout igp stale-route 0:01:10
user-identity default-domain LOCAL
aaa authentication ssh console LOCAL
aaa authentication login-history
no snmp-server location
no snmp-server contact
service sw-reset-button
crypto ipsec security-association pmtu-aging infinite
crypto ca trustpool policy
telnet timeout 5
ssh stricthostkeycheck
ssh 172.16.254.0 255.255.255.0 inside
ssh timeout 30
ssh version 2
ssh key-exchange group dh-group1-sha1
console timeout 0
dhcpd dns <my ISP DNS server 1> <my ISP DNS server 2>
dhcpd option 3 ip 172.16.254.1
!
dhcpd address 172.16.254.33-172.16.254.221 inside
dhcpd enable inside
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
dynamic-access-policy-record DfltAccessPolicy
username myuser password xxxxxxxxxxxx pbkdf2
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
no tcp-inspection
policy-map global_policy
class inspection_default
inspect ftp
inspect h323 h225
inspect h323 ras
inspect ip-options
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
inspect dns preset_dns_map
policy-map type inspect dns migrated_dns_map_2
parameters
message-length maximum client auto
message-length maximum 512
no tcp-inspection
policy-map type inspect dns migrated_dns_map_1
parameters
message-length maximum client auto
message-length maximum 512
no tcp-inspection
!
service-policy global_policy global
prompt hostname context
no call-home reporting anonymous
call-home
profile CiscoTAC-1
no active
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination address email callhome#cisco.com
destination transport-method http
subscribe-to-alert-group diagnostic
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily
Cryptochecksum:7bf6464dd03896f00321926e98426397
what is the CPU usage ?
also post here show interface gi1/1
Also try configuring manually on outside duplex full and speed auto or speed 1000
but before doing that post the stats of the outside interface first
i have created a linux tun interface, set ipaddr, broadcast etc.. using open/ioctl apis.
This is how the tun interface looks like,
TEST_TUN: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 45.45.45.1/24 scope global TEST_TUN
valid_lft forever preferred_lft forever
Any message written by a virtual host(binded on addr 45.45.45.1:udp=7070) is received by tun_fd(fd returned during tun device creation).
If tun_fd writes an msg ( IP(dst=45.45.45.1)+transport(udp_dst=7070)+payload) is not received on the virtual host. wireshark capture shows that the packet is being received on the kernel side, but virtual host doesnot received any packet.
what could be the reasons for kernel not forwarding the packet to virtual host ?
Had turned your tun device in up state?
if not then you can simply do that via..
$sudo ifconfig tun0 up
and you also can do that via ioctle commands..
if your device is already in a up state then you linux destro must have forwarding on..
you can do this via..
#echo "1" > /proc/sys/net/ipv4/ip_forwarding
or
$sudo sysctl net.ipv4.ip_forward=1
$sudo sysctl -p
then it comes to routing rules..you must have to set routing rule so that all the traffic is captured via your virtual interface..
$sudo ip route 128/1 dev tun
this command will add a route in you kernel routing table and all the traffic will flow through your virtual interface..
If I understood you correctly then may be this will be helpful for you..
As a stop-gap until Google supports native IPv6 on Google Compute Engine, I'd like to configure a 6in4 (IP protocol 41) tunnel.
I added a firewall rule to allow protocol 41 on my VM's network:
Name Source tag / IP range Allowed protocols / ports Target tags
allow-6in4 216.66.xxx.xxx 41 Apply to all targets
And configured the tunnel in /etc/network/interfaces:
auto 6in4
iface 6in4 inet6 v4tunnel
address 2001:470:xxxx:xxxx::2
netmask 64
endpoint 216.66.xxx.xxx
gateway 2001:470:xxxx:xxxx::1
ttl 64
up ip link set mtu 1280 dev $IFACE
And ping6 2001:470:xxxx:xxxx::1 and verified that 6in4 traffic was outbound:
$ sudo tcpdump -pni eth0 host 216.66.xxx.xxx
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:52:03.732841 IP 10.240.xxx.xxx > 216.66.xxx.xxx: IP6 2001:470:xxxx:xxxx::2 > 2001:470:xxxx:xxxx::1: ICMP6, echo request, seq 1, length 64
22:52:04.740726 IP 10.240.xxx.xxx > 216.66.xxx.xxx: IP6 2001:470:xxxx:xxxx::2 > 2001:470:xxxx:xxxx::1: ICMP6, echo request, seq 2, length 64
22:52:05.748690 IP 10.240.xxx.xxx > 216.66.xxx.xxx: IP6 2001:470:xxxx:xxxx::2 > 2001:470:xxxx:xxxx::1: ICMP6, echo request, seq 3, length 64
I changed the endpoint temporarily to an address where I can run tcpdump, and confirmed that packets are not arriving at the destination. I even tried NAT myself in case GCE wasn't doing this for 6in4 packets, but no luck (iptables -t nat -A POSTROUTING -p ipv6 -j SNAT --to-source 130.211.xxx.xxx).
Has anyone gotten a 6in4 tunnel to work on a GCE VM? Is there some magic setting I missed somewhere?
TL;DR: You can't.
Per Networking and Firewalls:
Traffic that uses a protocol other than TCP, UDP, and ICMP is blocked, unless explicitly allowed through Protocol Forwarding.
Per Protocol Forwarding:
Google Compute Engine supports protocol forwarding for the following
protocols:
AH: Specifies the IP Authentication Header protocol.
ESP: Specifies the IP Encapsulating Security Payload protocol.
SCTP: Specifies the Stream Control Transmission Protocol.
TCP: Specifies the Transmission Control Protocol.
UDP: Specifies the User Datagram Protocol.
Hence, a Protocol Forwarding rule needs to be for one of the following IP protocol numbers:
51 (AH)
50 (ESP)
132 (SCTP)
6 (TCP)
17 (UDP)
The Protocol Forwarding page makes it clear that other protocol numbers, such as 41 (6in4) are not supported:
Note: This is an exhaustive list of supported protocols. Only protocols that appear here are supported for protocol forwarding.
I have trouble connecting to the wifi network with my Raspberry Pi (Raspbian Wheezy) in combination with EDIMAX EW-7811UN Wireless USB Adapter.
I already used this combination to connect to my parents wifi (WPA with a non-hidden wifi) successfully.
/etc/network/interfaces
auto lo
iface lo inet loopback
iface eth0 inet static
address 192.168.2.128
netmask 255.255.255.0
gateway 192.168.2.1
auto wlan0
allow-hotplug wlan0
iface wlan0 inet static
address 192.168.2.128
netmask 255.255.255.0
gateway 192.168.2.1
wpa-ap-scan 1
wpa-ap-ssid 1
wpa-ssid "<SSID>"
wpa-psk "<PASS>"
My own wifi has the following configuration:
hidden SSID
TKIP+AES (WPA/WPA2) with PSK authentication
So I generated a PSK version of my wifi password:
$ wpa_passphrase "<SSID>" "<PASS>"
And configured these two files:
/etc/network/interfaces
auto lo
iface lo inet loopback
iface eth0 inet dhcp
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp
and /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="<SSID"
psk=<PSK>
proto=WPA2
key_mgmt=WPA_PSK
pairwise=CCMP
group=CCMP
auth_alg=OPEN
}
The USB Adapter and its module are working fine (lsusb, lsmod). And as I said, I already used the Raspberry Pi to connect to a network. But it does not seem work with the configuration I use at my own home. I get an "Network unreachable" error if I try to ping my router.
Resetting the Raspberry Pi is not an option, because I already put a lot of effort in its configuration.
Does anybody have a simular configuration with his own Raspberry Pi or knows how to solve this (I already googled and tried different "solutions" for hours without any success).
Thank you,
Freddi
I finally found my answer here (sorry, it is german): Raspberry Pi, Edimax EW-7811Un and a hidden wifi
# /etc/network/interfaces
allow-hotplug wlan0
auto wlan0
iface wlan0 inet dhcp
wpa-ap-scan 1
wpa-scan-ssid 1
wpa-ssid "SSID"
wpa-proto RSN
wpa-pairwise CCMP
wpa-key-mgmt WPA-PSK
wpa-psk "PASS"
I think you forgot in the first aproach adding
scan_ssid=1
to the network block in wpa_supplicant.conf to make the network work with hidden ssid.
From the docs:
scan_ssid
SSID scan technique; 0 (default) or 1. Technique 0 scans for the
SSID using a broadcast Probe Request frame while 1 uses a
directed Probe Request frame. Access points that cloak them-
selves by not broadcasting their SSID require technique 1, but
beware that this scheme can cause scanning to take longer to com-
plete.
How can i use tcpdump to capture Ethernet frames and display any frame sent or received by the local PC with one of the UDP, ARP, and ICMP protocols.
I was trying this command:
sudo tcpdump -e udp or arp or icmp
but, i thinks it's wrong.
I can give you an example, how you can capture enthernet frame from your localhost.
sudo tcpdump -i lo -nnvvvexxXXKS -s0
for capturing the frame we used "exxXX"
Do use tcpdump -e. Here's an example of the output:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:36:02.408697 02:42:ac:11:00:02 (oui Unknown) > 02:42:ac:11:00:03 (oui Unknown), ethertype IPv4 (0x0800), length 74: client.60546 > yahoo.com.80: Flags [S], seq 1673384407, win 64240, options [mss 1460,sackOK,TS val 2181456358 ecr 0,nop,wscale 7], length 0
In this example, you can see frame fields such as the MAC addresses (e.g. 02:42:ac:11:00:03) and the frame type (e.g. ethertype IPv4 0x0800).
From the manpage:
If the '-e' option is given, the link level header is printed out. On Ethernets, the source and destination addresses, protocol, and packet length are printed.
On FDDI networks, the '-e' option causes tcpdump to print the `frame control' field, the source and destination addresses, and the packet length. (The `frame control' field governs the interpretation of the rest of the packet. Normal packets (such as those containing IP datagrams) are `async' packets, with a priority value between 0 and 7; for example, `async4'. Such packets are assumed to contain an 802.2 Logical Link Control (LLC) packet; the LLC header is printed if it is not an ISO datagram or a so-called SNAP packet.
On Token Ring networks, the '-e' option causes tcpdump to print the `access control' and `frame control' fields, the source and destination addresses, and the packet length. As on FDDI networks, packets are assumed to contain an LLC packet. Regardless of whether the '-e' option is specified or not, the source routing information is printed for source-routed packets.
On 802.11 networks, the '-e' option causes tcpdump to print the `frame control' fields, all of the addresses in the 802.11 header, and the packet length. As on FDDI netâworks, packets are assumed to contain an LLC packet.
First of all, you are interested in packets, not frames. Frames are a layer below packets and only chip manufacturers are concerned with them. Second, you must specify your interface with the -i switch or promiscuous mode won't be even activated for you to see everything - if that's what you want.