IPSec - src and dst mac don't change from encrypted to decrypted packets
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I am trying to debug an IPSec setup. I have 4 virtualbox vms:
client a in address 192.168.224.2/24
My own IPSec gateway with addresses 192.168.224.5/24 and 192.168.10.100/24
A strongswan IPSec gateway with addresses 192.168.225.5/24 and 192.168.10.101/24
client b in address 192.168.225.2/24
I set up a tunnel between 192.168.10.100 and 192.168.10.101. I am trying to ping from 192.168.224.2 to 192.168.225.2 and I am not getting an answer. I also enabled routing on the strongswan machine (net.ipv4.ip_forward=1).
I tried to track the packets using wireshark and this is what I saw:
ICMP request sent correctly from client a to my gateway
ESP packet sent from my gateway to the strongswan machine
the packet is received by the strongswan machine and decrypted back to an ICMP request, but the MAC addresses on the wireshark capture of the decrypted packet are wrong - the src and dst MAC addresses are the same as the ones on the received ESP packet, and not changed as they should be according to the next hop - the source MAC should be the strongswan machine and the destination MAC should be client b. What am I doing wrong?
Thanks.
routing ipsec strongswan
asked Dec 15 '17 at 21:11
barisdad
11
add a comment |Â
up vote
0
down vote
favorite
I am trying to debug an IPSec setup. I have 4 virtualbox vms:
client a in address 192.168.224.2/24
My own IPSec gateway with addresses 192.168.224.5/24 and 192.168.10.100/24
A strongswan IPSec gateway with addresses 192.168.225.5/24 and 192.168.10.101/24
client b in address 192.168.225.2/24
I set up a tunnel between 192.168.10.100 and 192.168.10.101. I am trying to ping from 192.168.224.2 to 192.168.225.2 and I am not getting an answer. I also enabled routing on the strongswan machine (net.ipv4.ip_forward=1).
I tried to track the packets using wireshark and this is what I saw:
ICMP request sent correctly from client a to my gateway
ESP packet sent from my gateway to the strongswan machine
the packet is received by the strongswan machine and decrypted back to an ICMP request, but the MAC addresses on the wireshark capture of the decrypted packet are wrong - the src and dst MAC addresses are the same as the ones on the received ESP packet, and not changed as they should be according to the next hop - the source MAC should be the strongswan machine and the destination MAC should be client b. What am I doing wrong?
Thanks.
routing ipsec strongswan
asked Dec 15 '17 at 21:11
barisdad
11
I actually think you are describing normal behaviour. would you expand the question to try to describe what is wrong with the packet(s)?
– Rui F Ribeiro
Dec 16 '17 at 10:45
I enabled routing on the strongswan machine so I think it should be sent to client b's MAC and not the strongswan machine's MAC. I will edit.
– barisdad
Dec 16 '17 at 12:35
The client MAC is not send in normal routing, and much less in VPN. It is normal behaviour. I would suggest you (re)visiting CCNA study material.
– Rui F Ribeiro
Dec 16 '17 at 13:02
I don't think we understand each other. Shouldn't the packet be forwarded from the strongswan machine to client b?
– barisdad
Dec 16 '17 at 14:53
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am trying to debug an IPSec setup. I have 4 virtualbox vms:
client a in address 192.168.224.2/24
My own IPSec gateway with addresses 192.168.224.5/24 and 192.168.10.100/24
A strongswan IPSec gateway with addresses 192.168.225.5/24 and 192.168.10.101/24
client b in address 192.168.225.2/24
I set up a tunnel between 192.168.10.100 and 192.168.10.101. I am trying to ping from 192.168.224.2 to 192.168.225.2 and I am not getting an answer. I also enabled routing on the strongswan machine (net.ipv4.ip_forward=1).
I tried to track the packets using wireshark and this is what I saw:
ICMP request sent correctly from client a to my gateway
ESP packet sent from my gateway to the strongswan machine
the packet is received by the strongswan machine and decrypted back to an ICMP request, but the MAC addresses on the wireshark capture of the decrypted packet are wrong - the src and dst MAC addresses are the same as the ones on the received ESP packet, and not changed as they should be according to the next hop - the source MAC should be the strongswan machine and the destination MAC should be client b. What am I doing wrong?
Thanks.
routing ipsec strongswan
asked Dec 15 '17 at 21:11
barisdad
11
I am trying to debug an IPSec setup. I have 4 virtualbox vms:
client a in address 192.168.224.2/24
My own IPSec gateway with addresses 192.168.224.5/24 and 192.168.10.100/24
A strongswan IPSec gateway with addresses 192.168.225.5/24 and 192.168.10.101/24
client b in address 192.168.225.2/24
I set up a tunnel between 192.168.10.100 and 192.168.10.101. I am trying to ping from 192.168.224.2 to 192.168.225.2 and I am not getting an answer. I also enabled routing on the strongswan machine (net.ipv4.ip_forward=1).
I tried to track the packets using wireshark and this is what I saw:
ICMP request sent correctly from client a to my gateway
ESP packet sent from my gateway to the strongswan machine
the packet is received by the strongswan machine and decrypted back to an ICMP request, but the MAC addresses on the wireshark capture of the decrypted packet are wrong - the src and dst MAC addresses are the same as the ones on the received ESP packet, and not changed as they should be according to the next hop - the source MAC should be the strongswan machine and the destination MAC should be client b. What am I doing wrong?
Thanks.
routing ipsec strongswan
asked Dec 15 '17 at 21:11
barisdad
11
edited Dec 16 '17 at 12:38
asked Dec 15 '17 at 21:11
barisdad
11
asked Dec 15 '17 at 21:11
barisdad
11
asked Dec 15 '17 at 21:11
barisdad
11
11
I actually think you are describing normal behaviour. would you expand the question to try to describe what is wrong with the packet(s)?
– Rui F Ribeiro
Dec 16 '17 at 10:45
I enabled routing on the strongswan machine so I think it should be sent to client b's MAC and not the strongswan machine's MAC. I will edit.
– barisdad
Dec 16 '17 at 12:35
The client MAC is not send in normal routing, and much less in VPN. It is normal behaviour. I would suggest you (re)visiting CCNA study material.
– Rui F Ribeiro
Dec 16 '17 at 13:02
I don't think we understand each other. Shouldn't the packet be forwarded from the strongswan machine to client b?
– barisdad
Dec 16 '17 at 14:53
add a comment |Â
I actually think you are describing normal behaviour. would you expand the question to try to describe what is wrong with the packet(s)?
– Rui F Ribeiro
Dec 16 '17 at 10:45
I enabled routing on the strongswan machine so I think it should be sent to client b's MAC and not the strongswan machine's MAC. I will edit.
– barisdad
Dec 16 '17 at 12:35
The client MAC is not send in normal routing, and much less in VPN. It is normal behaviour. I would suggest you (re)visiting CCNA study material.
– Rui F Ribeiro
Dec 16 '17 at 13:02
I don't think we understand each other. Shouldn't the packet be forwarded from the strongswan machine to client b?
– barisdad
Dec 16 '17 at 14:53
I actually think you are describing normal behaviour. would you expand the question to try to describe what is wrong with the packet(s)?
– Rui F Ribeiro
Dec 16 '17 at 10:45
I actually think you are describing normal behaviour. would you expand the question to try to describe what is wrong with the packet(s)?
– Rui F Ribeiro
Dec 16 '17 at 10:45
I enabled routing on the strongswan machine so I think it should be sent to client b's MAC and not the strongswan machine's MAC. I will edit.
– barisdad
Dec 16 '17 at 12:35
I enabled routing on the strongswan machine so I think it should be sent to client b's MAC and not the strongswan machine's MAC. I will edit.
– barisdad
Dec 16 '17 at 12:35
The client MAC is not send in normal routing, and much less in VPN. It is normal behaviour. I would suggest you (re)visiting CCNA study material.
– Rui F Ribeiro
Dec 16 '17 at 13:02
The client MAC is not send in normal routing, and much less in VPN. It is normal behaviour. I would suggest you (re)visiting CCNA study material.
– Rui F Ribeiro
Dec 16 '17 at 13:02
I don't think we understand each other. Shouldn't the packet be forwarded from the strongswan machine to client b?
– barisdad
Dec 16 '17 at 14:53
I don't think we understand each other. Shouldn't the packet be forwarded from the strongswan machine to client b?
– barisdad
Dec 16 '17 at 14:53
add a comment |Â
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f411143%2fipsec-src-and-dst-mac-dont-change-from-encrypted-to-decrypted-packets%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
I actually think you are describing normal behaviour. would you expand the question to try to describe what is wrong with the packet(s)?
– Rui F Ribeiro
Dec 16 '17 at 10:45
I enabled routing on the strongswan machine so I think it should be sent to client b's MAC and not the strongswan machine's MAC. I will edit.
– barisdad
Dec 16 '17 at 12:35
The client MAC is not send in normal routing, and much less in VPN. It is normal behaviour. I would suggest you (re)visiting CCNA study material.
– Rui F Ribeiro
Dec 16 '17 at 13:02
I don't think we understand each other. Shouldn't the packet be forwarded from the strongswan machine to client b?
– barisdad
Dec 16 '17 at 14:53