- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
May 7 2024
The current workaround is manual DNAT rules:
set nat destination rule 100 destination port '80' set nat destination rule 100 protocol 'tcp' set nat destination rule 100 translation redirect port '3128'
Add any rules before 100 for excluding DNAT and use "bypass"
Few PR checks failing, i will check and fix
Used codeql reusable workflow in a reference repo.
Please review and merge
https://github.com/vyos/vyos-1x/pull/3420
Min config for old implementation with redirect (1.2):
set service webproxy listen-address 192.168.122.12 set service webproxy url-filtering squidguard block-category 'aggressive' set service webproxy url-filtering squidguard local-block 'mytest.local' set service webproxy whitelist destination-address '192.0.2.1' set service webproxy whitelist destination-address '192.0.2.2' set service webproxy whitelist source-address '192.0.2.222' set service webproxy whitelist source-address '192.0.2.223'
Added reusable workflow for codeql
Please review and approve
https://github.com/vyos/vyos-github-actions/pull/2
There is an ongoing discussion in the background between the maintainers for more then a year how to get rid of the hw-id node in general and do such a detection once during initial boot.
May 6 2024
And similar example, using same interfaces and host, but instead of GRE tunnel, using a Wireguard site to site tunnel:
Example of using flowtables on mater interfaces, and communication between a local host that is on a VLAN (vlan eth2.22 and host 10.22.22.222), and a remote host that is reachable through a GRE tunnel (tunnel established using interface eth0):
By looking at this and the documentation, I do not see any proofs that flowtables support any encapsulation except VLAN and PPPOE.
Can you try with newver version?
New fixes were applied.
You can check this tasks:
https://vyos.dev/T6269
https://vyos.dev/T6191