Jump to content

IPSec туннель с доступом в интернет


Recommended Posts

13 минуты назад, Le ecureuil сказал:

Начиная со следующей сборки draft автопрописывание роута к destination должно работать :) 

При переходе на резерв будет корректно переключаться маршрут на резервный канал? А если уже есть маршрут до этого узла? А то я теперь осмыслил, что у меня при резерве через 3G туннель-то и не работал (основной канал давно не падал, так что на практике не обнаруживал)

Т.е. я рассматриваю два случая с автотуннелями с default route на туннель:

1) к серверу подключается по беляку, стандартное резервирование проводного инета мобильным модемом, при переходе на резерв маршрут перепишется?

2) Опять резерв, но уже специально жестко прописан destination ip маршрутом через проводной инет. Возможна ситуация, когда основной инет лежит, но по локалке сервер доступен (и там есть инет), т.е. мне именно надо чтобы в случае падения сети был вариант остаться на туннеле, и только потом уходить на модем. Собственно, сейчас только так и можно сделать.

Edited by KorDen
Link to comment
Share on other sites

7 минут назад, KorDen сказал:

При переходе на резерв будет корректно переключаться маршрут на резервный канал? А если уже есть маршрут до этого узла? А то я теперь осмыслил, что у меня при резерве через 3G туннель-то и не работал (основной канал давно не падал, так что на практике не обнаруживал)

Т.е. я рассматриваю два случая с автотуннелями с default route на туннель:

1) к серверу подключается по беляку, стандартное резервирование проводного инета мобильным модемом, при переходе на резерв маршрут перепишется?

2) Опять резерв, но уже специально жестко прописан destination ip маршрутом через проводной инет. Возможна ситуация, когда основной инет лежит, но по локалке сервер доступен (и там есть инет), т.е. мне именно надо чтобы в случае падения сети был вариант остаться на туннеле, и только потом уходить на модем. Собственно, сейчас только так и можно сделать.

На драфте и попробуем эти сценарии :wink:

Link to comment
Share on other sites

Ребята, а не подскажите как правильно ping-check прописать для IPIP0 в моей ситуации? Чтобы был рестарт интерфейса на стороне клиента в случае если перестает пинговаться офисный роутер/статический внешний IP. Пытался искать и сам пробовал разобраться, но что-то по ходу я не в силах понять,как создать новый профиль через командную строку.

Link to comment
Share on other sites

@intelworker, так уже есть DPD-интервал IPsec в 30 секунд, и по нему вроде бы вполне рестартуется соединение, по крайней мере у меня соединение достаточно быстро восстанавливается после рестарта роутера-сервера.

Link to comment
Share on other sites

А как посмотреть включен ли он для интерфейса IPIP0? Это же все через командную строку так понимаю смотреть, в вебе я этого всего для IPIP не увижу

В справочнике команд есть только упоминание dpd для профилей crypto ipsec. А пока настроил такой вот ping-check, вроде даже работает и проверяет, осталось дождаться поведения при фейлах.

ping-check profile IPIP0
    host 8.8.8.8
    update-interval 30
    mode icmp
    max-fails 5
    timeout 10
    restart-interface
 show ping-check IPIP0

        pingcheck:
              profile: IPIP0

                 host: 8.8.8.8

      update-interval: 30
            max-fails: 5
              timeout: 10
                 mode: icmp

            interface:
                     name: IPIP0
             successcount: 6
                failcount: 0
                   status: pass

 

Edited by intelworker
Link to comment
Share on other sites

7 часов назад, intelworker сказал:

А как посмотреть включен ли он для интерфейса IPIP0? Это же все через командную строку так понимаю смотреть, в вебе я этого всего для IPIP не увижу

В справочнике команд есть только упоминание dpd для профилей crypto ipsec. А пока настроил такой вот ping-check, вроде даже работает и проверяет, осталось дождаться поведения при фейлах.


ping-check profile IPIP0
    host 8.8.8.8
    update-interval 30
    mode icmp
    max-fails 5
    timeout 10
    restart-interface

 show ping-check IPIP0

        pingcheck:
              profile: IPIP0

                 host: 8.8.8.8

      update-interval: 30
            max-fails: 5
              timeout: 10
                 mode: icmp

            interface:
                     name: IPIP0
             successcount: 6
                failcount: 0
                   status: pass

 

DPD это встроенный механизм контроля работы туннеля ipsec для контроля именно туннеля никаких дополнительных пингчеков не надо, и так должно работать с настройками по умолчанию..

Link to comment
Share on other sites

Ну, через час после того как я это ping-check прописал у меня роутер просто повис походу, видать IP на модеме сменился и что-то пошло не так. До этого просто была такая ситуация что IP видать тоже сменился, а туннель об этом узнал через час или более, как итог, отсутствие инета полностью час и более. Не понимаю что с этим делать пока.

Link to comment
Share on other sites

10 минут назад, intelworker сказал:

Ну, через час после того как я это ping-check прописал у меня роутер просто повис походу, видать IP на модеме сменился и что-то пошло не так. До этого просто была такая ситуация что IP видать тоже сменился, а туннель об этом узнал через час или более, как итог, отсутствие инета полностью час и более. Не понимаю что с этим делать пока.

Выкладывать селфтесты для разработчиков если есть подозрение на баг :wink:

Link to comment
Share on other sites

Проблема в том, что я это могу делать только ночью когда время появляется, попробую селф-тесты позже. Сейчас журналы просмотрел и судя по всему что-то происходит с туннелем когда синхронизируется время, а не когда IP на модеме сменяется. В прошлый раз в журнале тоже самое наблюдал, последние записи были относительно обновления времени, а потом мертвая тишина в логе.

[I] Aug 18 00:40:26 ndm: Ntp::Client: unable to communicate with "0.pool.ntp.org".
[I] Aug 18 00:40:26 ndm: Ntp::Client: could not synchronize, waiting...
[I] Aug 18 00:40:26 ndm: kernel: EIP93: build outbound ESP connection, (SPI=c5b3432f)
[I] Aug 18 00:40:26 ndm: kernel: EIP93: build  inbound ESP connection, (SPI=c254ab9e)
[I] Aug 18 08:48:50 ndm: Core::System::Clock: system time has been changed.
[I] Aug 18 08:48:53 ipsec: 05[CFG] system time jump detected from 1503006024s to 1503035333s, initiate SA rekeying 
[I] Aug 18 08:48:53 ipsec: 05[IKE] establishing CHILD_SA IPIP0 

Понимаю, этот кусок лога мало что скажет разработчику, но вот в логе записей нет после 00:40, хотя по логам приложений запущенных на ноуте, интернет пропал в 1:44, т.е. через час после последней записи. Часовые пояса настроены верно, если что. В 8:48 я выключил/включил роутер.

Edited by intelworker
Link to comment
Share on other sites

16 часов назад, KorDen сказал:

При переходе на резерв будет корректно переключаться маршрут на резервный канал? А если уже есть маршрут до этого узла? А то я теперь осмыслил, что у меня при резерве через 3G туннель-то и не работал (основной канал давно не падал, так что на практике не обнаруживал)

Т.е. я рассматриваю два случая с автотуннелями с default route на туннель:

1) к серверу подключается по беляку, стандартное резервирование проводного инета мобильным модемом, при переходе на резерв маршрут перепишется?

2) Опять резерв, но уже специально жестко прописан destination ip маршрутом через проводной инет. Возможна ситуация, когда основной инет лежит, но по локалке сервер доступен (и там есть инет), т.е. мне именно надо чтобы в случае падения сети был вариант остаться на туннеле, и только потом уходить на модем. Собственно, сейчас только так и можно сделать.

Будет. Если обнаружено, что туннель упал, то эти автороуты сбрасываются и начинается их новое определение.

Если есть маршрут - ничего страшного, новая запись будет проигнорирована.

1) да

2) будет работать как сделаете, если он прописан через другой интерфейс - должен выбраться путь через него.

  • Thanks 1
Link to comment
Share on other sites

13 часа назад, intelworker сказал:

А как посмотреть включен ли он для интерфейса IPIP0?

show ipsec

...
Connections:
VirtualIPServer:  %any...%any  IKEv1, dpddelay=20s
VirtualIPServer:   local:  [mykeenetic.net] uses pre-shared key authentication
VirtualIPServer:   remote: uses pre-shared key authentication
VirtualIPServer:   remote: uses XAuth authentication: eap
VirtualIPServer:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=restart
       IPIP0:  x.x.x.x...y.y.y.y  IKEv2, dpddelay=30s
       IPIP0:   local:  [IPIP0] uses pre-shared key authentication
       IPIP0:   remote: [IPIP0] uses pre-shared key authentication
       IPIP0:   child:  0.0.0.0/0[ipencap] === y.y.y.y/32[ipencap] TRANSPORT, dpdaction=restart
       IPIP1:  a.b.c.d...%any  IKEv2, dpddelay=30s
       IPIP1:   local:  [IPIP1] uses pre-shared key authentication
       IPIP1:   remote: [IPIP1] uses pre-shared key authentication
       IPIP1:   child:  e.f.g.h/32[ipencap] === 0.0.0.0/0[ipencap] TRANSPORT, dpdaction=restart

 

Link to comment
Share on other sites

8 минут назад, KorDen сказал:

show ipsec


...
Connections:
VirtualIPServer:  %any...%any  IKEv1, dpddelay=20s
VirtualIPServer:   local:  [mykeenetic.net] uses pre-shared key authentication
VirtualIPServer:   remote: uses pre-shared key authentication
VirtualIPServer:   remote: uses XAuth authentication: eap
VirtualIPServer:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=restart
       IPIP0:  x.x.x.x...y.y.y.y  IKEv2, dpddelay=30s
       IPIP0:   local:  [IPIP0] uses pre-shared key authentication
       IPIP0:   remote: [IPIP0] uses pre-shared key authentication
       IPIP0:   child:  0.0.0.0/0[ipencap] === y.y.y.y/32[ipencap] TRANSPORT, dpdaction=restart
       IPIP1:  a.b.c.d...%any  IKEv2, dpddelay=30s
       IPIP1:   local:  [IPIP1] uses pre-shared key authentication
       IPIP1:   remote: [IPIP1] uses pre-shared key authentication
       IPIP1:   child:  e.f.g.h/32[ipencap] === 0.0.0.0/0[ipencap] TRANSPORT, dpdaction=restart

 

просто 
> show interface IPIP0

вам тоже это покажет

Link to comment
Share on other sites

26 минут назад, Le ecureuil сказал:

просто 
> show interface IPIP0

вам тоже это покажет

DPD-интервала там нет, только

tunnel-local-source: 1.2.3.4
tunnel-remote-destination: 5.6.7.8
    ipsec-enabled: yes
ipsec-ikev2-allowed: yes
ipsec-ikev2-enabled: yes
ipsec-encryption-level: strong

 

Link to comment
Share on other sites

В 17.08.2017 в 18:43, Le ecureuil сказал:

Начиная со следующей сборки draft автопрописывание роута к destination должно работать :) 

@Le ecureuil Маршрут добавляется, спасибо. Буду тестить.

Тем временем новая хотелка:

Сейчас туннели over  ipsec считаются поднятыми всегда независимо от реального состояния.

Из-за этого при использовании туннеля в качестве маршрута по умолчанию при падении канала не происходит ухода на резерв.

Так же после перезагрузки возникает ситуация что интернет не доступен так как поднимается туннельный интерфейс с максимальным приоритетом но не может поднять соединение так как так как идет попытка получить tunnel destination через себя же(в случае если нет днс прописанного жестко через определенный работающий интерфейс).

Хотелось бы получить сходное поведение с PPTP соединениями и им подобными и для автоматических туннелей over ipsec

PS как я понимаю подобное было сделано для OpenVPN соединений в крайнем драфте

  • Thanks 1
Link to comment
Share on other sites

2 часа назад, r13 сказал:

@Le ecureuil Маршрут добавляется, спасибо. Буду тестить.

Тем временем новая хотелка:

Сейчас туннели over  ipsec считаются поднятыми всегда независимо от реального состояния.

Из-за этого при использовании туннеля в качестве маршрута по умолчанию при падении канала не происходит ухода на резерв.

Так же после перезагрузки возникает ситуация что интернет не доступен так как поднимается туннельный интерфейс с максимальным приоритетом но не может поднять соединение так как так как идет попытка получить tunnel destination через себя же(в случае если нет днс прописанного жестко через определенный работающий интерфейс).

Хотелось бы получить сходное поведение с PPTP соединениями и им подобными и для автоматических туннелей over ipsec

PS как я понимаю подобное было сделано для OpenVPN соединений в крайнем драфте

Спасибо за комментарии, поработаем над этим.

  • Upvote 1
Link to comment
Share on other sites

@Le ecureuil Протестировал маршрут до узла,

с авто туннелями все четко. (тестировал с и без маршрутом добавленным вручную 2 параллельных туннеля к 1й точке IPIP и PPTP)

А вот PPTP наоборот после отключения пересоздает маршрут.

В логе следующее:

Скрытый текст

Aug 20 19:10:37ndm
Network::Interface::Base: "PPTP0": interface is down.
Aug 20 19:10:37ndhcpc
PPTP0: sendmsg() failed (invalid argument).
Aug 20 19:10:37ndhcpc
PPTP0: can not send RELEASE (invalid argument) in RELEASING state.
Aug 20 19:10:37ndm
kernel: Fast VPN ctrl: release for src 77.22.136.81
Aug 20 19:10:37pppd_PPTP0
MPPE disabled
Aug 20 19:10:37pppd_PPTP0
Connection terminated.
Aug 20 19:10:37ndm
Dhcp::Client: DHCP server is not responding.
Aug 20 19:10:37ndm
Network::Interface::IP: "PPTP0": IP address cleared.
Aug 20 19:10:37pppd_PPTP0
Closing connection (unhandled)
Aug 20 19:10:37pppd_PPTP0
Sent control packet type is 12 'Call-Clear-Request'
Aug 20 19:10:37pppd_PPTP0
Closing connection (call state)
Aug 20 19:10:37pppd_PPTP0
Terminating on signal 15
Aug 20 19:10:37pppd_PPTP0
Exit.
Aug 20 19:10:37ndm
Network::Interface::Base: "PPTP0": interface is down.
Aug 20 19:10:37ndm
Network::Interface::Ppp: "PPTP0": disabled connection.
Aug 20 19:10:37ndm
Network::Interface::PppTunnel: "PPTP0": remote endpoint is resolved to "77.22.136.81".
Aug 20 19:10:37ndm
Network::Interface::PppTunnel: "PPTP0": local endpoint is resolved to "192.168.1.66" (via "FastEthernet0/Vlan2").
Aug 20 19:10:37ndm
Network::Interface::PppTunnel: "PPTP0": added host route to 77.22.136.81 via 192.168.1.1 (FastEthernet0/Vlan2).
Aug 20 19:10:37ndm
Network::Interface::Ppp: "PPTP0": connection service standby.
Aug 20 19:10:37ndm
Network::Interface::Ppp: "PPTP0": enabled connection via any interface.
Aug 20 19:10:39ndm
Process: "PPTP0 DHCP client" has been killed.

Так же при запуске роутера даже отключенный PPTP создает маршрут:

Скрытый текст
Aug 20 19:01:46ndm
IpSec::CryptoEngineManager: hardware crypto processing was enabled.
Aug 20 19:01:46ndm
Http::Manager: new Web server configuration was applied.
Aug 20 19:01:47ndhcpc
FastEthernet0/Vlan2: NDM DHCP client (version 3.2.11) started.
Aug 20 19:01:47ndhcpc
FastEthernet0/Vlan2: created PID file "/var/run/ndhcpc-eth2.2.pid".
Aug 20 19:01:48ndhcpc
FastEthernet0/Vlan2: received OFFER for 192.168.1.66 from 192.168.1.1.
Aug 20 19:01:49ndhcpc
FastEthernet0/Vlan2: received ACK for 192.168.1.66 from 192.168.1.1.
Aug 20 19:01:49ndm
Dhcp::Client: configuring interface ISP.
Aug 20 19:01:49ndm
Network::Interface::IP: "FastEthernet0/Vlan2": IP address is 192.168.1.66/24.
Aug 20 19:01:49ndm
Dhcp::Client: obtained IP address 192.168.1.66/24.
Aug 20 19:01:49ndm
Dhcp::Client: interface "ISP" is global, priority 700.
Aug 20 19:01:49ndm
Dhcp::Client: adding a default route via 192.168.1.1.
Aug 20 19:01:49ndm
Dhcp::Client: adding name server 192.168.1.1.
Aug 20 19:01:49ndm
Dns::Manager: name server 192.168.1.1 added, domain (default).
Aug 20 19:01:49ndm
Network::InterfaceFlusher: flushed conntrack and route cache.
Aug 20 19:01:51ndm
Network::Interface::Ppp: "PPTP0": disabled connection.
Aug 20 19:01:51ndm
Network::Interface::PppTunnel: "PPTP0": remote endpoint is resolved to "77.22.136.81".
Aug 20 19:01:51ndm
Network::Interface::PppTunnel: "PPTP0": local endpoint is resolved to "192.168.1.66" (via "FastEthernet0/Vlan2").
Aug 20 19:01:51ndm
Network::Interface::PppTunnel: "PPTP0": added host route to 77.22.136.81 via 192.168.1.1 (FastEthernet0/Vlan2).
Aug 20 19:01:51ndm
Network::Interface::Ppp: "PPTP0": connection service standby.
Aug 20 19:01:51ndm
Network::Interface::Ppp: "PPTP0": enabled connection via any interface.

 

Edited by r13
Link to comment
Share on other sites

17 часов назад, r13 сказал:

@Le ecureuil Протестировал маршрут до узла,

с авто туннелями все четко. (тестировал с и без маршрутом добавленным вручную 2 параллельных туннеля к 1й точке IPIP и PPTP)

А вот PPTP наоборот после отключения пересоздает маршрут.

В логе следующее:

  Показать содержимое

Так же при запуске роутера даже отключенный PPTP создает маршрут:

  Показать содержимое

 

Это не баг, это фича.

PPP-интерфейсы нужно отключать не через up/down, а через connect / no connect. В противном случае PPP-линк все равно будет установлен, однако интерфейс будет опущен.

  • Thanks 1
Link to comment
Share on other sites

4 минуты назад, Le ecureuil сказал:

Это не баг, это фича.

PPP-интерфейсы нужно отключать не через up/down, а через connect / no connect. В противном случае PPP-линк все равно будет установлен, однако интерфейс будет опущен.

Ок, попробую с connect / no connect

Кстати, галка в веб интерфейсе в настройках PPTP делает up/down или connect / no connect?

Link to comment
Share on other sites

1 минуту назад, r13 сказал:

Ок, попробую с connect / no connect

Кстати, галка в веб интерфейсе в настройках PPTP делает up/down или connect / no connect?

Она делает connect / no connect.

  • Thanks 1
Link to comment
Share on other sites

В 8/19/2017 в 12:13, r13 сказал:

@Le ecureuil Маршрут добавляется, спасибо. Буду тестить.

Тем временем новая хотелка:

Сейчас туннели over  ipsec считаются поднятыми всегда независимо от реального состояния.

Из-за этого при использовании туннеля в качестве маршрута по умолчанию при падении канала не происходит ухода на резерв.

Так же после перезагрузки возникает ситуация что интернет не доступен так как поднимается туннельный интерфейс с максимальным приоритетом но не может поднять соединение так как так как идет попытка получить tunnel destination через себя же(в случае если нет днс прописанного жестко через определенный работающий интерфейс).

Хотелось бы получить сходное поведение с PPTP соединениями и им подобными и для автоматических туннелей over ipsec

PS как я понимаю подобное было сделано для OpenVPN соединений в крайнем драфте

В следующей сборке draft должно работать. Просьба проверить.

  • Upvote 1
Link to comment
Share on other sites

7 часов назад, Le ecureuil сказал:

Это не баг, это фича.

PPP-интерфейсы нужно отключать не через up/down, а через connect / no connect. В противном случае PPP-линк все равно будет установлен, однако интерфейс будет опущен.

потестил с no connect, все отлично работает :)

Link to comment
Share on other sites

@Le ecureuil Смоделировал ситуацию "криворучки", когда PPTP интерфейс уже создал свой роут через ISP

а у IPIP интерфейса указан source PPTP а не ISP

в этом случае:

Aug 21 21:12:02ndm
Network::Interface::Tunnel: "IPIP4": resolved destination 77.23.136.81 (*.mykeenetic.net).
Aug 21 21:12:02ndm
Network::Interface::Tunnel: "IPIP4": resolved source 192.168.5.204.
Aug 21 21:12:03ndm
Network::Interface::Tunnel: "IPIP4": system failed [0xcffd0464], unable to get route to tunnel destination endpoint.

Понятно что настройка кривовата но надо бы подкрутить обработку исключения.

Edited by r13
Link to comment
Share on other sites

12 часа назад, r13 сказал:

@Le ecureuil Смоделировал ситуацию "криворучки", когда PPTP интерфейс уже создал свой роут через ISP

а у IPIP интерфейса указан source PPTP а не ISP

в этом случае:


Aug 21 21:12:02ndm
Network::Interface::Tunnel: "IPIP4": resolved destination 77.23.136.81 (*.mykeenetic.net).
Aug 21 21:12:02ndm
Network::Interface::Tunnel: "IPIP4": resolved source 192.168.5.204.
Aug 21 21:12:03ndm
Network::Interface::Tunnel: "IPIP4": system failed [0xcffd0464], unable to get route to tunnel destination endpoint.

Понятно что настройка кривовата но надо бы подкрутить обработку исключения.

В каком плане подкрутить? Не выводить? Нет уж, пусть юзер с кривоватыми настройками это видит и беспокоится, а потом и настроит соответствующе.

И вообще одновременное задание source и destination у туннеля с ipsec является логической ошибкой - должно быть либо то, либо другое, ибо оно включает режим клиента или сервера.

Link to comment
Share on other sites

3 часа назад, Le ecureuil сказал:

В каком плане подкрутить? Не выводить? Нет уж, пусть юзер с кривоватыми настройками это видит и беспокоится, а потом и настроит соответствующе.

И вообще одновременное задание source и destination у туннеля с ipsec является логической ошибкой - должно быть либо то, либо другое, ибо оно включает режим клиента или сервера.

Подкрутить в плане выводить без "system failed"

A без указания tunnel source на клиенте в случае еще одного туннеля в тот же destination не получается,

Иначе в моем случае IPIP нуннель идет через роут через ISP при этом резолвя source oт PPTP0 интерфейса. IPIP туннель при этом не поднимается.

В случае же указатия и source и destanation все заводится. Но это частный случай. в общем случае да, достаточно указать только destination на клиенте.

Фактически указание tunnel source на клиенте это аналог настройки "Подключаться через" у других соединений.

Edited by r13
Link to comment
Share on other sites

@Le ecureuil

Ставлю экспериент:

Основное соединение ISP

Если Поверх него в качестве интернет соединения поднят PPTP то последующий IPIP интерфейс поднимается через PPTP0.

Если же поверх ISP в качестве интернет соединения поднят IPIP то последующее поднятие  PPTP интерфейсa поднимается через ISP.

PPTP настроен как подключаться через любое интернет подключение.

Почему такие различия в поведении?

селфтест далее.

Link to comment
Share on other sites

Потому что вы в одну и ту же точку соединяетесь по этим туннелям. IPIP уже прописал host route к 77.37.136.81 через 192.168.1.1, потому PPTP тоже подбирает этот маршрут.

Link to comment
Share on other sites

34 минуты назад, Le ecureuil сказал:

Потому что вы в одну и ту же точку соединяетесь по этим туннелям. IPIP уже прописал host route к 77.37.136.81 через 192.168.1.1, потому PPTP тоже подбирает этот маршрут.

В обоих случаях один из интерфейсов создает этот host route

Вопрос про различие в выборе sorce интерфейса:

IPIP похоже выбирает тот что является default route(и поэтому соединение идет через PPTP), а PPTP тот что определил из таблицы роутинга а именно ISP из этой записи host route.

Или не так?

Link to comment
Share on other sites

  • 3 months later...
В 26.11.2017 в 14:26, r13 сказал:

Все сделал по инструкции, но не заработало. Я правильно понимаю, что у домашнего роутера при правильных настройках должен появится внешний ИП адрес как у офисного? 

Ошибка в логах Dec 01 14:54:33ndm

IpSec::Configurator: general error while establishing crypto map "IPIP0" connection.
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...