I’m using Linux 2.6.32 device that establishes a VPN connection. When VPN is up, all packets sent by the device, includes the VPN client src address.
ICMP packets continuously go through the VPN interface and successfully encrypted/decrypted, and after that they are sent to the WLAN via the WLAN interface (as ESP packet with the VPN Interface as src ip).
After disabling the VPN, the VPN interface goes down, ICMP packets are sent directly to the WLAN interface (with the WLAN Interface as src ip) in plaintext un-encrypted.
But when the VPN is established again and the VPN interface is up again, packets are sent at the same way, but the ESP packet encapsulates a WLAN src IP and not the VPN src IP.
ICMP packets go through the VPN interface and then via WLAN interface as ESP packet with the WLAN Interface as src ip and not VPN Interface as src ip.
The only way to have the ESP packets leave with the VPN IP address encapsulated is either:
Wait until the machines "nf_conntrack_icmp_timeout" expires, and restart ping application.
Remove the WLAN interface (ifconfig down) and set it up again (ifconfig up).
Both solutions are not appropriate, as I don’t want to stop the ping and I don’t want to reconfigure the device network interface.
I tried to clear the routing cache by:
echo 1 > /proc/sys/net/ipv4/route/flush
And I also tried to clear the ARP cache by:
ip -s -s neigh flush all
Is there another way to clear all active session, after the VPN is going down?
Related
Hints about working with VLAN? I have to write a client-server program, where the client will send a packet through eth0 and the server will receive the packet on VLAN, and to send it to a concerned VLAN client should parse on which command line VLAN will receive it?
Usually there is nothing to do in the application to work with a VLAN. The VLAN is realized using a virtual network interface with its own IP address. From the perspective of the application this is not different from a real network interface with own IP address. The OS will take care about routing and encapsulation of packets and there is nothing to do from the application itself.
I have been working on CISCO's SMA390 and the RPC port for the device is not responsive when connected to a core switch.
1. The core switch is for public-facing IP/ CIMC IP of the device.
2. The IP's are configured and using ipmitool command.
3. The port is responding when tried to configure over a private network(laptop to device connection).
I have tried ping command after checking that the IP's are configured and its failing while the gateway is responding.
ipmitool lan print 1
ipmitool lan set 1 ipsrc static
ipmitool lan set 1 ipaddr 10.10.1.5
ipmitool lan set 1 netmask 255.255.255.0
ipmitool lan set 1 defgw ipaddr 10.10.1.1
ipmitool lan set 1 access on
ipmitool raw 0x36 0x52 0x0f
I want the ping and the ssh to be enabled.
I figured out after some more troubleshooting that CISCO x90 devices by default work on 100G bandwidth connection. The default provided on x95 devices is 1000G bandwidth connection. Hence the RPC port didn't respond.
If you face this issue, try
1. using a 100G connection.
2. change the default connection acceptance bandwidth of your device(i.e x90 here).
My Linux (Debian) server has eth0 and eth1, and both are on the same subnet.
It receives packets from both interfaces, but it only replies from eth0.
Packets that are sent to eth1 are replied from eth0, and the reply has eth0's src mac and eth1's src IP.
I verified this by sending a ping to eth1 while running tcpdump on the Linux server.
This is a problem because:
Since no packets are sent with a source mac of eth1 (with the exception of the initial arp), the switch forgets the eth1 mac. Then, every packet with the destination mac of eth1 that is received by the switch is broadcasted across the network, flooding it which makes us sad.
I want:
My Linux server to send packets out from both eth0 and eth1. I think the nicest solution is that for each packet we get, we reply from the same interface. Another way to put it is that I want to bind each interface to its IP and MAC - so that it will only send packets from these addresses.
More details:
My Linux server is an ISCSI Target communicating with an ESX which is an ISCSI Initiator - though a Cisco switch. The switch forgets MACs after 5 minutes, and the ESX probably remembers them for 20 minutes (as discussed here and here). So while the ESX remembers the mac of the Linux, the ESX keeps sending ISCSI requests which flood the network, while my server sends ISCSI replies through only one of the interfaces.
This isn't what you asked for, but if you just set up a cron job on the box that did
ping -c 1 -I eth1 <address of eth1's default gateway>
every minute, then you would have at least one packet per minute leaving eth1 with eth1's MAC address on it. -I tells ping to bind to a specific interface, so it won't use eth0 even if that's the preferred route.
i'm triying to imagine how to do:
(with Linux Debian based distro)
I have PC with 4 NIC:
eth0 = Internet Access (connect to router WAN)
eth1 = Local lan
eth2 = OUT NIC
eth3 = IN NIC
I need to send all traffic from eth1 (local lan) to eth2, receive the same traffic from eth3 and route to eth0.
The idea is send all eth1 traffic to external device over eth2, the external device inspect the packets and send to PC again on eth3, then my PC Linux route traffic to eth0
Is posible to do that ?
You're running linux on a PC? We need to know the version first off. Second you are looking into IProutes if you want to redirect traffic from one NIC to another.
I have two machines each with two valid network interfaces, an Ethernet interface eth0 and a tun/tap interface gr0. The goal is to start a TCP connection on machine A using interface gr0 but then have the responses (ACKs, etc) from machine B come back over the Ethernet interface, eth0. So, machine A sends out a SYN on gr0 and machine B receives the SYN on its own gr0 but then sends its SYN/ACK back through eth0. The tun/tap device is a GNU Radio wireless link and we just want the responses to come through the Ethernet.
What's the easiest way to accomplish this? I need to research more on TCP/IP, but I was initially thinking that source-spoofing outgoing packets would tell the receiver to respond to the spoofed address (which should get routed to eth0). This would involve routing the IPs from the tun/tap interfaces through gr0 and leave the other traffic to eth0.
We are using Linux and a Python solution would be preferable.
Thanks for looking!
You could add an additional address to the lo interface on each system and use these new addresses as the TCP connection endpoints. You can then use static routes to direct which path each machine takes to get to the other machine's lo address.
For example:
Machine A:
ip addr add 1.1.1.1/32 dev lo
ip route add 2.2.2.2/32 dev eth0 via <eth0 default gateway>
Machine B:
ip addr add 2.2.2.2/32 dev lo
ip route add 1.1.1.1/32 dev gr0
Then bind to 1.1.1.1 on machine A and connect to 2.2.2.2.
You may be interested in enabling logging of martian packets net.ipv4.conf.all.log_martians, and disable reverse path filtering net.ipv4.conf.<interface>.rp_filter on the affected interfaces.
This sysctl vars are accesible via the sysctl utility and/or the /proc filesystem.