Проблема е тичиен за линукс базираните рутери. Състои се в това, че се добвят точни правила в iptables -t nat -A PREROUTING, които са валидни само за пакети, които идват в рутера през WAN интерфейса.
Виж скрита или допълнителна опция в пренасочващото правило, която да го направи валидно, за пакети идващи от всички интерфейси.

Не си губи времето, ползвай Windows.

Вероятно имаш проблем с рутирането. Не може да правиш следното:
ip a add 10.11.12.1/24 dev br1
ip a add 10.11.12.2/24 dev br2

Трябва да е:
ip a add 10.11.12.1/32 dev br1
ip a add 10.11.12.1/32 dev br2

И статично рутиране за хостовете, ако искаш да са в една подмрежа.
Според мен няма нужда от толкова бриджове. Второто реалното IP също може да се добави директно на едната виртуалка...

Пълен лаик съм в мрежите, затова се надявам да сте разбрани.
Имам две мрежи всяка по отделно свързани към Интернет(през рутер).

Това е работа за администратор, освен ако не си такъв. Няма лошо да си администратор и да не разбираш, но поне си направи труда да обясниш каква е заварената ти мрежа.
Какви са тези две мрежи? За физически отделени мрежи ли говориш или за подмрежи (192.168.0.0/24 192.168.1.0/24)?
Използвай IP адреси вместо N1 и N2.
Какъв е този рутер Cisco, Mikrotik, Linux, BSD? Двата доставчика в един и същи рутер ли влизат?

Обясни подробно как ти е изградена лан мрежата и тогава очаквай помощ.

Добави в началото
<VirtualHost>
и в края
</VirtualHost>
и пробвай

Мисля си нещо за 50-100 лева. Според мен не би трябвало да отнеме повече от няколко часа.

За тази сума трудно, ще намериш някой.
Ако все пак намериш, този програмист, другия път ще знае, че за подобна сума не трябва да се захваща за работа.

Аз също ползвам xfce. Ако ми се занимава, правя минимална инсталация на debian и xfce. Ако не ми се занимава, правя стандартна инсталация.
Инсталирам много малко допълнителни програми, една от тях е geany. Тя поддържа отваряне на файла в нов таб и оцветява избрания низ.

[два пъти]

Малко теория, в FreeBSD и базираните дистрибуции всеки пакет се проверява два пъти в Layer 3. Ако ipfw/pf работят и на Layer 2 тогава всеки пакет минава 4 проверки.

Движението на пакета в мрежовия стек обобщено изглежда така:
драйвер на лан карта -> вход (IN) -> ipfw/pf (първа проверка) -> изход (OUT) -> ipfw/pf (втора проверка) -> драйвер на лан карта

Политиката по-подразбиране е drop. За да се виждат под мрежите 192.168.3.0/24 <-> 192.168.15.0/24 трябва, да се добавят две правила:

1. src 192.168.3.0/24 -> dst 192.168.15.0/24
2. src 192.168.15.0/24 -> dst 192.168.3.0/24

Така за всички мрежи или може да се използват две двойки правила с in, out на интерфейс.
Най-добре е, да се използват таблици, където да се опишат под мрежите.

nat-та не е като в Линукс, даже всичко да е добре направено, калпави нат правила, може да счупят много неща.

Ако Gec даде читави логове от pf, някой който разбира от pf може да му помогне.
Защитна стена с уеб интерфейс не означава, готово решение на проблеми, ако не знаеш какво правиш. Не напразно хората предлагат платена поддръжка и основно печелят от там.

Готов съм да пращам скриинове ако трябва и достъп отдалечен да изляза от тая каша

Ако дадеш информацията, която исках...

В BSD дистрибуциите има голяма свобода за писане на правила в защитната стена, но тя работи на коренно различен принцин в сравнение с тази на Линукс. Трябва да знаеш какво правиш.

Ако имаш достъп от главния pfSense към вътрешните мрежи на останалите рутери, предполагам, че е проблем със защитната стена.

Ако използваш ipfw, какъв е изхода от командата:

Код:

ipfw -a list

Ако използваш pf, не мога да ти помогна, потърси в интернет.

Какво има в рутиращата таблица (скрий си част от реалните IP адреси):

Код:

netstat -r

Ако имаш познати техници в някой интернет доставчик, помоли ги да ти замерят влакната с power meter. Първо се мери, ако има проблеми се чисти и после пак се мери. Процедурата се повтаря и от двата края. Когато влакното се включва в SFP модула, трябва да се внимава върха да не опре никъде, иначе множе да се зацапа и започват проблемите.

В наще среди не съм чувал, някой да използва mikrotik като суич. Вече има втора ръка Cisco на достъпна цена с 10Gb модули.

[две правила]

Конфигурационни файлове, които се използват от php:
/etc/imslu/config.php - съдържа общи конфигурационни променливи
/etc/imslu/database_config.php - съдържа променливи за база данни
include/os.php - изберете каква ОС използвате, по подразбиране е FreeBSD

/etc/imslu/config.sh  - съдържа общи конфигурационни променливи, които се използват от скриптовете.

За някои потребители може да изглежда малко объркващо и сигурно се питат, дали има нужда от конфигурационни файлове, скриптове, ...?

Идеята е проста.
Конфигурационните файлове съдържат най-общите системни настройки и позволяват лесна промяна на стойности, без да се правят промени по кода.
В база данни се съхранява останалата информация.
Уеб интерфейса променя данните в база данни и стартира functions-php.sh скрипта, за да приложи новите промени.
sh скриптовете имат достъп до системата и прилагат промените.

/etc/rc.local:

. /etc/imslu/config.sh
. /etc/imslu/scripts/functions.sh
Включва променливи от конф. файл и системни функции.

####### IMQ #######
Правилата трябва да се разкоментират, ако imq модула не е част от ядрото. На IMQ интерфейсите не създават правилата за шейпъра.

##### ADD VLANS #####
Тази функция се намира в functions.sh и служи за автоматично създаване на виртуални интерфейси. Разгледайте променливата VLAN_SEQ в /etc/imslu/config.sh, тя определя колко и с какво id да бъдат vlan-ните.

####### ipset #######
Създават се ipset таблици, за да се използват по-късно. ipset създава хеш таблици, чрез които се прави много бърза проверка, дали пакета отговаря на даденото правило. С едно ipset правило може да се заменят много iptables правила.

### kinds of traffic ###
Маркира се входящ и изходящ трафик, който не е български (международен). Българския трафик се използва повече, поради което маркираме международни. Ако има обратна тенденция могат да им се сменят местата, но това ще наложи промени и в другите скриптове. Маркираме може би, не е правилния израз, понеже iptables разполага и с инструмент "-j MARK". Мисля, че "-j TOS" е по-бърза операция в сравнение с "-j MARK", ако греша моля да ме поправите.

### Shaper ###
Тези правила пренасочват трафика за ограничаване на скоростт в IMQ интерфейса.

# Dynamic NAT
Тези правила са интересни. DNETMAP модула позволява частни мрежи да се nat-ват с част или цяла публична подмрежа.

# Redirect expiret users to warning page
Това правило излишно проверява уеб трафика, за да пренасочи неплатилите клиенти към старицата за предупреждение.
Не ми харесва, че има такова правило, но не мога да намеря по-елегантно решение.
Ако има начин това да се прави във FORWARD таблицата, след като е минала проверката за плащането, ще е перфектно.

# NAT
Няма какво да обяснявам.

# Set default policy for chain FORWARD to DROP
Запазва се минимален лог и се извършва проверка за платили клиенти. "-m set --match-set allowed" таблица allowed съдържа IP адреси на клиенти, които са платили услугата. С ipset проверката става чрез бързи хеш таблици и само с две правила.

Разгледайте /etc/imslu/scripts/start.sh има интересни команди. Този скрипт работи с БД, за да създаде правилата за щейпър, платили клиенти, рутиране, mac защита.

Отворен съм на всякакви предложения, за оптимизиране на производителността.
Писането не ми е силната страна, ако имате въпроси, питайте.

Искам да дам малко информация за отговора, който писах в друга тема относно линукс рутер и защитна стена.

Линукс рутера, през който минават почти 9 Gb трафик работи с ipacct.com
Линукс защитната стена, през която минават над 100 Gb трафик се разработва от млад човек, който е изключително в час, в тази област.

Тази информация я споделям, за да знаете, че в България също има много добри специалисти.
Моето лично мнение е, че ако държавата използва подобни специалисти, няма да има новините от типа:
- атаки блокираха работата на държавно учреждение, защото преди да падне услугада на това учреждение, че паднат много големи доставчици.
!!! Моля не доразвивайте тази теория в тази тема. Може да отворим друга тема, ако има интерес!!!

Предполагам, че във форума има потребители, които се занимават сериозно с мрежово администриране. Ако дадат своето мнение, за използваните инструменти и начина на работа на системата, ще съм им благодарен.

Системата се стартира в тори ред, Линукс :
rc.local - създава vlan-ни, iptables правила, ipset таблици
start.sh - създава правила за шейпъра, добавя рутиране за IP адреси по интерфейсите, пуска mac защита, проверява платилите клиенти

Ако има интерес, мога да обясня по-подробно.

Замисли се над това, защо във всички теми отворени от теб, преобладаващото мнение е, че нещата не се правят така? Включително и аз мисля така.

Ако след време се окаже, че си бил прав и всичко работи като песен, ще си призная, че съм сгрешил.
Ако преобладаващото мнение се окажа право, замислял ли си се, как ще се поддържа това нещо?
Клиентите дали, ще искат да разберат, че някои предишни обещания няма как да се изпълнят?
От опит знам, че щом е безплатно клиента го иска, особенно ако му е обещано и после си брани придобивките със зъби и нокти.

Всички сървъри, които искаш да инсталираш на една купчина в една машина и после това решени, да го предлагаш, си имат своите особенности. Щом си решил  да използваш Unix подобна ОС рано или късно, ще опреш до конзолата.

Искаш да оправиш БД, пусни mysqlcheck, може да загубиш малко информация, но ще ти съживи БД. Но това няма да отстрани причината на проблема.

Не използвам Ubuntu, освен Xubuntu на домашния ми лаптоп. Малко ме дразни, защото пуска връзки към разни места и пречи на тестовете ми.

python, sh, php ... всички стават и вършат работа, най-добре е да работеш с това, с което ти е най-удобно.
Но аз трябваше, да се спра на стандартен скриптов език като sh, който го има във всяка Unix подобна система. И преобладаващите системни скриптове са писани на sh.

php кода може, да се изпълнява директно от конзолата, примерно:
$ php database/import-ipacct-database.php