[strongSwan] dns problem when using the dhcp plugin

[Noel Kuntze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

As Simon already pointed out, you can use the policy module in iptables to match traffic that is matches an IPsec policy,
hence strems from an IPsec packet or is going to be transformed into an IPsec packet.
If I remember correctly, you can use the extra_match option in the UCI configuration of the firewall
to add this criteria to the Zone definition.
To make two way communication work, you also have to ACCEPT the packets in the zone definition for your IPsec zone
in the *nat POSTROUTING chain before the MASQUERADE zone for traffic from the LAN zone to the WAN zone applies.
The cause of the problem is, that by default, traffic forwarded to other Zones does not have an ACCEPT rule
in the *nat POSTROUTING chain for the special chain that would contain the MASQUERADE rule, if you applied
masquerading to traffic going out of the zone, that it would fall through to your MASQUERADE rule for
the LAN to WAN traffic, causing packets that are going from your LAN to an IPsec peer to be masqueraded.
That would break two way connectivity.

Mit freundlichen Grüßen/Regards,
Noel Kuntze

Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 09.12.2014 um 20:24 schrieb Hasse Hagen Johansen:
> Hi Thanks for helping
> 
> The DHCP is assigning the right ip adress for the DNS server. I also tried it on a windows7 ipsec client from work today and it gets the right DNS assigned, but will still resolve to the external even though it asks the right DNS server.
> 
> I have found the problem. It is because I have made special rules for the static IP in the firewall that it works. The strongswan is running on openwrtand I think I made those firewall rules to get the VPN to hit the internal resolver so I will get the internal DNS instead of external
> 
> That is because the client will hit the "zone_wan" even though the ip-address is in the lan address range
> 
> So I have these rules:
> 
> Chain zone_wan (1 references)
> target     prot opt source               destination
> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:68
> ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 8
> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:500
> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:4500
> ACCEPT     tcp  --  192.168.100.50       0.0.0.0/0           tcp dpt:53
> ACCEPT     udp  --  192.168.100.50       0.0.0.0/0           udp dpt:53
> input_wan  all  --  0.0.0.0/0            0.0.0.0/0
> zone_wan_REJECT  all  --  0.0.0.0/0            0.0.0.0/0
> 
> I did this as quick fix because I couldn't figure out how to match the vpn client as source. Is there anyway how to match packages coming from the vpn clients? Earlier when you had like a vpn interface in linux it would be easier. Then I could add it to the lan zone, but I don't know how it is done now?
> 
> Best Regards and sorry for the confusion
> 
> Hasse
> 
> 
> 
> Den 09/12/14 kl. 10:13 skrev Martin Willi:
>> Hi,
>>
>>> When using a static ip in the rightsourceip parameter the
>>> client(android) is resolving my mailserver with the internal ip as it
>>> should(because I set that up with the attr plugin), but when using
>>> rightsourceip=%dhcp the settings for dns with attr plugin seems to be
>>> ignored and then the client doesn't even get the dns assigned which the
>>> dhcp says it should use (and then my mailserver resolves to the external
>>> ip which cannot be accessed)
>> Please note that the DHCP plugin forwards any DNS/WINS attributes it
>> receives over DHCP to the client using IKE configuration attributes. If
>> you have both the attr and the dhcp plugin enabled, strongSwan sends the
>> DNS attributes of each backend.
>>
>> Does your DHCP server provide the correct DNS server address? If yes,
>> you may try to disable the attr plugin.
>>
>>>>                           enc = 0
>> Unfortunately, with that loglevel setting we don't see the messages
>> encoded/decoded, which is actually very useful information. If you
>> revert to the default loglevels, we'd see at least how many DNS
>> attributes strongSwan assigns to the client.
>>
>> Regards
>> Martin
>>
> 
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJUh1KyAAoJEDg5KY9j7GZY0dEP/21+eVgSPVNbDcsmYv0cSUZX
o1WPKsidzw/wMiGHo5rN5ibpuU5XxHScb7Y9WiwwfyFoq4IvfPexKoiTxYqXg0U0
lQ1nBj7sUi0oxcnXPLeDrs0KPsI1IAEFSdNIXvtx/nXvoSCbP8+dYK55ng1tOw4h
EFvHlSBx/hOWhlrt/mKMVKOXac39uTQJw270b88F+AwQI+R3luBSMi2Pz3liLo5l
tLaEgDTKqqIQwc+nWmyNP9lML/mpg4xgXvW0CcXN+7uOUWRH8XFjzscTqLhLN19q
IzYeTIFiEgJR27P1XHT4Wyws0BtWQtW4X6pQ++9FVtBBJW6EZGths+hx1TkIo5MT
437Es4nd0KzmivKSSiaHGYxmsl1JqF0y4FjLb+7QRYNG7gIPilPLbHjW9DVVLsb7
Y+36yrk5huVGqQk5Nmto9OaIdwHRARd5sflrB3Xj7pnfDKprk/ik66kVrlQZy0xB
8nKlNKE4Fcsj2WFCVRuPOQFzi1UmVY9+iJKm+DMur/F4H2Z67kyWsJUi6Q+Bm1nA
0WYN/A6cPtjpWDE8uMYFvNRLdI+JZhh/x9kUUjXLQ+WK+lfUotlPuzJRfb3cQMlT
AI4VI7Fy3lYjhAkcf1Rb6QWfG4eyylIMA8e5Wtp4n1aEi4IBQKpurKamaoz75sIe
O/0oNzXKRRoFD1w3w7Nb
=8JHP
-----END PGP SIGNATURE-----