Re: IPv4 traffic over IPv6 tunnel approach
gif(4) should work fine, as it's designed to do what you described. The best approach depends on the level of security you want to achieve. IPIP tunnels aren't encrypted... regards, kristjan On 5/8/20 3:32 PM, Martin wrote: > I have IPv6 unidirectional tunnel between two machines. One of them is > gateway, another one is a client. > The goal is to route IPv4 packets over IPv6 tunnel from client to gateway and > NAT IPv4 packet to egress on gateway machine. > > May I use gif(4) for it or what is the best approach to traverse IPv4 packets > over IPv6 tun? > > Martin >
Re: OpenBSD insecurity rumors from isopenbsdsecu.re
On 5/7/20 7:02 PM, Aaron Mason wrote: > On Fri, May 8, 2020 at 2:30 AM jeanfrancois wrote: >> >> As long as there's no material published it's worth just any other word. >> > > To quote Douglas Adams on whether you can trust people on the > internet, "of course not, it's just people talking". > wait a minute. you are on the internet, I am on the internet. I CAN"T TRUST ANYONE. MY LIFE IS FALLING APART. but then I shouldn't trust what you said too. Ah, okok, i'll not trust what you said *promptly goes to the nearest zebra crossing to get killed* (sorry I just had to)
gnutls cannot connect to openbsd.org -- TLS 1.3 issue?
Hi, starting a couple of days ago, applications linked against gnutls can no longer connect to https://www.openbsd.org. Short output: $ gnutls-cli openbsd.org Processed 133 CA certificate(s). Resolving 'openbsd.org:443'... Connecting to '129.128.5.194:443'... *** Fatal error: An illegal parameter has been received. $ gnutls-cli -v gnutls-cli 3.6.10 More debug output can be produced with "gnutls-cli -d 999 openbsd.org". The interesting part is probably this: |<4>| HSK[0x1f80fb31a000]: CERTIFICATE VERIFY (15) was received. Length 516[516], frag offset 0, frag length: 516, sequence: 0 |<4>| HSK[0x1f80fb31a000]: Parsing certificate verify |<4>| HSK[0x1f80fb31a000]: verifying TLS 1.3 handshake data using RSA-SHA256 |<3>| ASSERT: signature.c[_gnutls_session_sign_algo_enabled]:364 |<4>| Signature algorithm RSA-SHA256 is not enabled |<3>| ASSERT: tls13-sig.c[_gnutls13_handshake_verify_data]:75 |<3>| ASSERT: tls13/certificate_verify.c[_gnutls13_recv_certificate_verify]:131 |<3>| ASSERT: handshake-tls13.c[_gnutls13_handshake_client]:144 |<13>| BUF[HSK]: Emptied buffer *** Fatal error: An illegal parameter has been received. Can be reproduced on OpenBSD 6.6-stable with gnutls from ports. (But it affects my Linux boxes, too.) It only fails with gnutls, so I first reported it there: https://gitlab.com/gnutls/gnutls/-/issues/984 However, Daiki Ueno said it looks like an issue with LibreSSL. Quoting in full: > This looks like an issue in the server side (LibreSSL). In TLS 1.3, > non-PSS RSA signature schemes have been removed, while the server > seems to sign the Certificate Verify message with RSA-SHA256, which is > not permitted. I'm not really an expert on TLS or cryptography, so no idea what's going on, which is why I'm reporting it on misc first. :-) Should this be reported to libre...@openbsd.org? Thanks in advance, Peter
Re: IPv4 traffic over IPv6 tunnel approach
Hi Martin, If I understand your question correctly you need 2 endpoints to the tunnel... for gif(4) or any gre((4) based tunnel you need the interface setup on both the client and the server (gateway) if you have a gateway serving multiple clients... then you need one interface per client that you intend to connect Thanks Tom Smyth On Fri, 8 May 2020 at 17:38, Martin wrote: > > Thanks for confirmation. > > Hope I understand gif(4) functionality right from its configuration. Can I > set /etc/hostname.gif0 from client's side only like below: > > /etc/hostname.gif0 > tunnel 10.20.30.40 195.203.212.221 > inet6 alias 2001:05a8::0001::::8542 128 > dest 2001:05a8::0001::::8541 > > where > tunnel 10.20.30.40 is client's address, 195.203.212.221 gateway machine > egress IPv4 > inet6 alias is the same IPv6 address of client's IPv6 local interface or an > IPv6 address in the same subnet. > dest IPv6 is a destination IPv6 interface address of gateway machine. > > Do I need to setup gif0 on gateway machine to have encapsulation working? > > Martin > > ‐‐‐ Original Message ‐‐‐ > On Friday, May 8, 2020 1:43 PM, Kristjan Komlosi > wrote: > > > gif(4) should work fine, as it's designed to do what you described. The > > best approach depends on the level of security you want to achieve. IPIP > > tunnels aren't encrypted... > > > > regards, kristjan > > > > On 5/8/20 3:32 PM, Martin wrote: > > > > > I have IPv6 unidirectional tunnel between two machines. One of them is > > > gateway, another one is a client. > > > The goal is to route IPv4 packets over IPv6 tunnel from client to gateway > > > and NAT IPv4 packet to egress on gateway machine. > > > May I use gif(4) for it or what is the best approach to traverse IPv4 > > > packets over IPv6 tun? > > > Martin > > -- Kindest regards, Tom Smyth.
IPv4 traffic over IPv6 tunnel approach
I have IPv6 unidirectional tunnel between two machines. One of them is gateway, another one is a client. The goal is to route IPv4 packets over IPv6 tunnel from client to gateway and NAT IPv4 packet to egress on gateway machine. May I use gif(4) for it or what is the best approach to traverse IPv4 packets over IPv6 tun? Martin
Re: OpenBSD VPS hoster with unlimited/limited nonfiltered traffic
(This is a cut-and-paste of something I sent in response to a similar question about FreeBSD last month.) I've been a customer of Panix (panix.com) for years and they're terrific. Inexpensive, flexible, responsive support, VERY high clue level, and proactive about patches/fixes. (There have been multiple instances in which they've fixed something before I knew it was a problem. They're fast, but deliberate: I don't think I've observed any instances where they had to back out a change.) They're also good about supporting pretty much whatever distribution you ask for: if there's customer demand/requests for it, they'll make it happen. ---rsk
Re: IPv4 traffic over IPv6 tunnel approach
Thanks for confirmation. Hope I understand gif(4) functionality right from its configuration. Can I set /etc/hostname.gif0 from client's side only like below: /etc/hostname.gif0 tunnel 10.20.30.40 195.203.212.221 inet6 alias 2001:05a8::0001::::8542 128 dest 2001:05a8::0001::::8541 where tunnel 10.20.30.40 is client's address, 195.203.212.221 gateway machine egress IPv4 inet6 alias is the same IPv6 address of client's IPv6 local interface or an IPv6 address in the same subnet. dest IPv6 is a destination IPv6 interface address of gateway machine. Do I need to setup gif0 on gateway machine to have encapsulation working? Martin ‐‐‐ Original Message ‐‐‐ On Friday, May 8, 2020 1:43 PM, Kristjan Komlosi wrote: > gif(4) should work fine, as it's designed to do what you described. The > best approach depends on the level of security you want to achieve. IPIP > tunnels aren't encrypted... > > regards, kristjan > > On 5/8/20 3:32 PM, Martin wrote: > > > I have IPv6 unidirectional tunnel between two machines. One of them is > > gateway, another one is a client. > > The goal is to route IPv4 packets over IPv6 tunnel from client to gateway > > and NAT IPv4 packet to egress on gateway machine. > > May I use gif(4) for it or what is the best approach to traverse IPv4 > > packets over IPv6 tun? > > Martin
Re: IPv4 traffic over IPv6 tunnel approach
>From your description, you want to pass IPv4 inside a tunnel that has an outer >protocol of IPv6. Your resulting hostname.gif0 looks like the exact opposite >of your description (IPv6 inside the tunnel with IPv4 outer). Clarify what you need please. Provide your existing hostname.if files for the other interfaces if you need to. > On May 8, 2020, at 3:09 PM, Martin wrote: > > Last thing I have to understand about gif(4) and IPv6 tunneling. > > Should I set gif(4) 'inet6 alias' = the same IPv6 of the local end of IPv6 > tunnel interface or just set 'inet6 alias' for gif(4) in tunnel's IPv6 subnet? > > Martin > > ‐‐‐ Original Message ‐‐‐ >>> On Friday, May 8, 2020 4:41 PM, Tom Smyth >>> wrote: >> Hi Martin, >> If I understand your question correctly >> you need 2 endpoints to the tunnel... >> for gif(4) or any gre((4) based tunnel >> you need the interface setup on both the client and the server (gateway) >> if you have a gateway serving multiple clients... then you need one >> interface per client that you intend to connect >> Thanks >> Tom Smyth >>> On Fri, 8 May 2020 at 17:38, Martin martin...@protonmail.com wrote: >>> Thanks for confirmation. >>> Hope I understand gif(4) functionality right from its configuration. Can I >>> set /etc/hostname.gif0 from client's side only like below: >>> /etc/hostname.gif0 >>> tunnel 10.20.30.40 195.203.212.221 >>> inet6 alias 2001:05a8::0001::::8542 128 >>> dest 2001:05a8::0001::::8541 >>> where >>> tunnel 10.20.30.40 is client's address, 195.203.212.221 gateway machine >>> egress IPv4 >>> inet6 alias is the same IPv6 address of client's IPv6 local interface or an >>> IPv6 address in the same subnet. >>> dest IPv6 is a destination IPv6 interface address of gateway machine. >>> Do I need to setup gif0 on gateway machine to have encapsulation working? >>> Martin >>> ‐‐‐ Original Message ‐‐‐ On Friday, May 8, 2020 1:43 PM, Kristjan Komlosi kristjan.koml...@gmail.com wrote: gif(4) should work fine, as it's designed to do what you described. The best approach depends on the level of security you want to achieve. IPIP tunnels aren't encrypted... regards, kristjan On 5/8/20 3:32 PM, Martin wrote: > I have IPv6 unidirectional tunnel between two machines. One of them is > gateway, another one is a client. > The goal is to route IPv4 packets over IPv6 tunnel from client to gateway > and NAT IPv4 packet to egress on gateway machine. > May I use gif(4) for it or what is the best approach to traverse IPv4 > packets over IPv6 tun? > Martin >> -- >> Kindest regards, >> Tom Smyth.
PC Engines APU2 Leds control
Dear all, I'm enjoying OpenBSD on PC Engines hardwares called APU2: https://www.pcengines.ch/apu2.htm There is 3 led, which could be very usefull to deliver informations to the endusers, but I never could control them with OpenBSD /o\ Is any way to make it work ? On PCEngines forum I got the following answer: >You cannot control the GPIOs on J20, because those are are driven by a NCT5104D and wbsio(4) only supports hardware monitoring. >The LEDs OTOH are on GPIOs of the AMD FCH. I am not a hardware guy, and OpenBSD seems to have a lot of drivers which attach - but probably none for those GPIOs. >If you want to dig deeper, there is AMD documentation for the FCH and also a linux driver called "amd-fch-gpio" >Update: There seems to be somebody, who worked on this a while ago on OpenBSD: https://marc.info/?l=openbsd-tech&m=155355977613046 Sacha.
IKEv2 VPN -- creating specific routes after sending 0.0.0.0/0 to a default gateway
I have a roadwarrior client with traffic to 0.0.0.0/0 going through a remote gateway. I would like to also send _some_ traffic to a more specific, different host. However, traffic to that more spefic host always tries to use the remote gateway's SPI. In other words, once I say "0.0.0.0/0," I can't ever specify a different gateway for some other traffic. -- begin /etc/iked.conf: # roadwarrior's iked.conf: remote_gw = "insert remote gw IP here" roadwarrior ="192.168.100.2" # on 192.168.100.0/24 othermachine = "172.16.0.15" # on 172.16.0.0/24 ikev2 'roadwarrior' active esp from $roadwarrior to \ 0.0.0.0/0 peer $remote_gw srcid $roadwarrior \ dstid $remote_gw ikev2 active esp from $roadwarrior to $othermachine local \ $roadwarrior peer $othermachine \ srcid $roadwarrior dstid $othermachine -- end /etc/iked.conf The problem seems to be that once I specify the 0.0.0.0/0, I don't see a way for the policy to othermachine to become effective. roadwarrior tries to always use the spi for remote_gw. This make sense, of course -- othermachine is going to match the policy and so the SA is created and the policy doesn't need to be evaluated further. So I tried: -- part of iked.conf: ikev2 quick active esp from$roadwarrior to \ $othermachine local \ $roadwarrior peer $othermachine srcid \ $roadwarrior dstid $othermachine ikev2 'roadwarrior' active esp from $roadwarrior \ to 0.0.0.0/0 \ peer $remote_gw srcid $roadwarrior dstid \ $remote_gw -- end iked.conf But this doesn't help. roadwarrior still tries to connect to othermachine using remote_gw's SPI. I can work around this by specifying every network instead of the one for othermachine, but I'm just wondering if there's some way to still use 0.0.0.0/0 for remote_gw and then give more specific routes to other gateways. (If roadwarrior and othermachine were instead on different subnets of 10.0.0.0/8, then specifiying every network other than 10.0.0.0/8 is a little bit more obvious than specifying every network other than both 192.168.100.0/24 and 172.16.0.0/24). I can also simply not use a VPN to othermachine by adding flow from $roadwarrior to $othermachine type bypass in /etc/ipspec.conf on roadwarrior and the corresponding other direction in othermachine's /etc/ipsec.conf. However, I notice that after a few hours, othermachine seems to forget this entry if it's also running IKEv2 connections to other machines, and that I have to /sbin/ipsecctl -f /etc/ipsec.conf again to make it bypass again. All three machines are runninng -current. Here's roadwarrior's uname -a: OpenBSD roadwarrior.local 6.7 GENERIC.MP#175 amd64 I will try to make the network setup more clear: roadwarrior (192.168.100.2/24) is behind internal_router with interfaces 192.168.100.1/24 and 172.16.0.2/24. othermachine (172.16.0.15/24) is behind firewall with internal interface 172.16.0.1/24 and pppoe0 for DSL. firewall and othermachine both have static routes to the 192.168.100.0/24 network. I've tried adding a static route from roadwarrior to othermachine just in case that might help, but nothing changed. Please note that othermachine can make IKEv2 connections to other hosts on roadwarrior's subnet (192.168.100.0/24), as long as they don't have default routes in /etc/iked.conf going to remote_gateway. Thank you for your help and patience! Overall I have to say that configuring Open IKEv2 is very easy and _just works_. Much much faster than running web traffic using ssh -D also! I really appreciate the FAQ on openbsd.org and all the great documentation. I know I'm probably just missing something obvious for this particular case, and really appreciate your help.
Re: OpenBSD insecurity rumors from isopenbsdsecu.re
I got mixed feelings... This list seems very cherry-picked from people with a predetermined disliking of OpenBSD. If you check out the mitigations tab, you won't be able to find anything new or undocumented there. It looks like we as a community triggered a guy who retaliated by key-smashing together a rather nonconstructive criticism of OpenBSD's security and code development process. At 17, I might not be experienced enough for my opinion to count very much, but this seems like bait to make people angry rather than a security effort worth mentioning. The difference between security researchers and that guy IMO is that researchers help fix the problems, that guy only points the problems out. We got a bully on our hands here. To any OpenBSD developers reading this, you rock! Keep up the good work. Kristjan On 5/7/20 4:00 PM, i...@aulix.com wrote: > Dear OpenBSD fans, > > Can you please comment negative appraisal from the following website: > > https://isopenbsdsecu.re/quotes/ > > I did not want to hurt anyone, just looking for a secure OS and OpenBSD > looked very nice to me before I have found this website. > > Kind Regards > signature.asc Description: OpenPGP digital signature
Re: IPv4 traffic over IPv6 tunnel approach
Last thing I have to understand about gif(4) and IPv6 tunneling. Should I set gif(4) 'inet6 alias' = the same IPv6 of the local end of IPv6 tunnel interface or just set 'inet6 alias' for gif(4) in tunnel's IPv6 subnet? Martin ‐‐‐ Original Message ‐‐‐ On Friday, May 8, 2020 4:41 PM, Tom Smyth wrote: > Hi Martin, > If I understand your question correctly > > you need 2 endpoints to the tunnel... > > for gif(4) or any gre((4) based tunnel > you need the interface setup on both the client and the server (gateway) > > if you have a gateway serving multiple clients... then you need one > interface per client that you intend to connect > Thanks > Tom Smyth > > On Fri, 8 May 2020 at 17:38, Martin martin...@protonmail.com wrote: > > > Thanks for confirmation. > > Hope I understand gif(4) functionality right from its configuration. Can I > > set /etc/hostname.gif0 from client's side only like below: > > /etc/hostname.gif0 > > tunnel 10.20.30.40 195.203.212.221 > > inet6 alias 2001:05a8::0001::::8542 128 > > dest 2001:05a8::0001::::8541 > > where > > tunnel 10.20.30.40 is client's address, 195.203.212.221 gateway machine > > egress IPv4 > > inet6 alias is the same IPv6 address of client's IPv6 local interface or an > > IPv6 address in the same subnet. > > dest IPv6 is a destination IPv6 interface address of gateway machine. > > Do I need to setup gif0 on gateway machine to have encapsulation working? > > Martin > > ‐‐‐ Original Message ‐‐‐ > > On Friday, May 8, 2020 1:43 PM, Kristjan Komlosi kristjan.koml...@gmail.com > > wrote: > > > > > gif(4) should work fine, as it's designed to do what you described. The > > > best approach depends on the level of security you want to achieve. IPIP > > > tunnels aren't encrypted... > > > regards, kristjan > > > On 5/8/20 3:32 PM, Martin wrote: > > > > > > > I have IPv6 unidirectional tunnel between two machines. One of them is > > > > gateway, another one is a client. > > > > The goal is to route IPv4 packets over IPv6 tunnel from client to > > > > gateway and NAT IPv4 packet to egress on gateway machine. > > > > May I use gif(4) for it or what is the best approach to traverse IPv4 > > > > packets over IPv6 tun? > > > > Martin > > -- > > Kindest regards, > Tom Smyth.
'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
Which 'quantum' resistant algorithms can be used right now to prevent data decryption in future by 'quantum' computers (when they can do this) of currently collected data flows? Martin
Re: OpenBSD VPS hoster with unlimited/limited nonfiltered traffic
Good choice. Do they provide IP addresses from data-center's pool where VPSes located or from ISP range? Martin ‐‐‐ Original Message ‐‐‐ On Friday, May 8, 2020 5:51 PM, Rich Kulawiec wrote: > (This is a cut-and-paste of something I sent in response to a similar > question about FreeBSD last month.) > > I've been a customer of Panix (panix.com) for years and they're terrific. > Inexpensive, flexible, responsive support, VERY high clue level, and > proactive about patches/fixes. (There have been multiple instances > in which they've fixed something before I knew it was a problem. > They're fast, but deliberate: I don't think I've observed any instances > where they had to back out a change.) > > They're also good about supporting pretty much whatever distribution you > ask for: if there's customer demand/requests for it, they'll make it happen. > > ---rsk
Re: macppc wsconsctl screen brightness
On Wed, May 06, 2020 at 06:51:21PM +0900, rgc wrote: > macppc.html shows i can do this via "wsconsctl -w XXX". > ** note that wsconsctl doesn't have a "-w" option so macppc.html might need > to be updated ** sent a patch to remove the "-w" in the HTML file wsconsctl code show the "w" option is for compatibility use and does really nothing. > brightness setting still works via ADB keyboard on my PowerBook6,7 (iBook G4) > but setting display.brightness from command line does nothing on this device > and on another device (PowerBook G4). both are radeondrm perusing the code ... it seems setting the brightness is only possible on vgafb. ~ rgc
Re: IPv4 traffic over IPv6 tunnel approach
Martin If I understand your question correctly ... PC1 --IPV6 Gateway1 so you have a public ipv6 address on PC1 and Gateway 1 hostname.gif should specify the real ipv6 address of PC1 and the real IPv6 address of gateway1 in it to establish the tunnel #setup the tunnel interface with a command similar to the following ifconfig gif1 tunnel PC1-IPV6Gateway1-IPV6 #setup an ip address (ipv4) on the gif tunnel ifconfig gif1 inet PC1-IPv4address/subnetmask and do the the gateway ifconfig gif1 tunnel Gateway1-IPV6 PC1-IPV6 setup gateway ipv4 address on tunnel interface you just cratesed ifconfig gif1 inet PC1-IPv4address/subnetmask then you just need to add a default IPv4 Route on the client to the gateway On Fri, 8 May 2020 at 20:05, Martin wrote: > > Last thing I have to understand about gif(4) and IPv6 tunneling. > > Should I set gif(4) 'inet6 alias' = the same IPv6 of the local end of IPv6 > tunnel interface or just set 'inet6 alias' for gif(4) in tunnel's IPv6 subnet? > > Martin > > ‐‐‐ Original Message ‐‐‐ > On Friday, May 8, 2020 4:41 PM, Tom Smyth > wrote: > > > Hi Martin, > > If I understand your question correctly > > > > you need 2 endpoints to the tunnel... > > > > for gif(4) or any gre((4) based tunnel > > you need the interface setup on both the client and the server (gateway) > > > > if you have a gateway serving multiple clients... then you need one > > interface per client that you intend to connect > > Thanks > > Tom Smyth > > > > On Fri, 8 May 2020 at 17:38, Martin martin...@protonmail.com wrote: > > > > > Thanks for confirmation. > > > Hope I understand gif(4) functionality right from its configuration. Can > > > I set /etc/hostname.gif0 from client's side only like below: > > > /etc/hostname.gif0 > > > tunnel 10.20.30.40 195.203.212.221 > > > inet6 alias 2001:05a8::0001::::8542 128 > > > dest 2001:05a8::0001::::8541 > > > where > > > tunnel 10.20.30.40 is client's address, 195.203.212.221 gateway machine > > > egress IPv4 > > > inet6 alias is the same IPv6 address of client's IPv6 local interface or > > > an IPv6 address in the same subnet. > > > dest IPv6 is a destination IPv6 interface address of gateway machine. > > > Do I need to setup gif0 on gateway machine to have encapsulation working? > > > Martin > > > ‐‐‐ Original Message ‐‐‐ > > > On Friday, May 8, 2020 1:43 PM, Kristjan Komlosi > > > kristjan.koml...@gmail.com wrote: > > > > > > > gif(4) should work fine, as it's designed to do what you described. The > > > > best approach depends on the level of security you want to achieve. IPIP > > > > tunnels aren't encrypted... > > > > regards, kristjan > > > > On 5/8/20 3:32 PM, Martin wrote: > > > > > > > > > I have IPv6 unidirectional tunnel between two machines. One of them > > > > > is gateway, another one is a client. > > > > > The goal is to route IPv4 packets over IPv6 tunnel from client to > > > > > gateway and NAT IPv4 packet to egress on gateway machine. > > > > > May I use gif(4) for it or what is the best approach to traverse IPv4 > > > > > packets over IPv6 tun? > > > > > Martin > > > > -- > > > > Kindest regards, > > Tom Smyth. > > -- Kindest regards, Tom Smyth.
mysteriously disappearing pf state entries
I'm running OpenBSD 6.6 operating as an inter-VLAN and border router
using pf. Recently I wanted to use a nondefault state timeout for some
UDP traffic traversing from my voip subnet to a provider off site.
Within pf, there are three rules involved. The first is for traffic
coming from the voip subnet, which gets a six minute state timeout and a
tag:
pass in quick on vlan110 proto udp from any to port = 9430 tag VOIP_UDP
keep state (udp.multiple 360)
Then there is a NAT rule:
match out on $ext_if from 10.128.0.0/16 nat-to { $ext_vip } sticky-address
And a rule giving the traffic going out to the Internet a six minute
timeout as well:
pass out quick on $ext_if proto udp tagged VOIP_UDP keep state
(udp.multiple 360)
This initially looks like it worked; after the initial connection:
bash-5.0# pfctl -v -s state | grep -A1 '110.73:9430'
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:00:00, expires in 00:06:00, 7:5 pkts, 4451:2203 bytes, rule 63
all udp 96.251.22.157:55202 (10.128.110.73:9430) -> 198.148.6.55:9430
MULTIPLE:MULTIPLE
age 00:00:00, expires in 00:06:00, 7:5 pkts, 4451:2203 bytes, rule
48, source-track
There are two states, one with the internal addressing and one for the
NAT translation, both with six minute timeouts. As time goes by:
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:00:08, expires in 00:05:54, 31:31 pkts, 16469:18285 bytes,
rule 63
all udp 96.251.22.157:55202 (10.128.110.73:9430) -> 198.148.6.55:9430
MULTIPLE:MULTIPLE
age 00:00:08, expires in 00:05:54, 31:31 pkts, 16469:18285 bytes,
rule 48, source-track
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:00:20, expires in 00:05:42, 31:31 pkts, 16469:18285 bytes,
rule 63
all udp 96.251.22.157:55202 (10.128.110.73:9430) -> 198.148.6.55:9430
MULTIPLE:MULTIPLE
age 00:00:20, expires in 00:05:42, 31:31 pkts, 16469:18285 bytes,
rule 48, source-track
More packets are seen, resetting the timeout:
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:00:23, expires in 00:05:58, 32:32 pkts, 16872:19073 bytes,
rule 63
all udp 96.251.22.157:55202 (10.128.110.73:9430) -> 198.148.6.55:9430
MULTIPLE:MULTIPLE
age 00:00:23, expires in 00:05:58, 32:32 pkts, 16872:19073 bytes,
rule 48, source-track
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:00:38, expires in 00:05:43, 32:32 pkts, 16872:19073 bytes,
rule 63
all udp 96.251.22.157:55202 (10.128.110.73:9430) -> 198.148.6.55:9430
MULTIPLE:MULTIPLE
age 00:00:38, expires in 00:05:43, 32:32 pkts, 16872:19073 bytes,
rule 48, source-track
again:
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:00:41, expires in 00:06:00, 33:33 pkts, 17275:19931 bytes,
rule 63
all udp 96.251.22.157:55202 (10.128.110.73:9430) -> 198.148.6.55:9430
MULTIPLE:MULTIPLE
age 00:00:41, expires in 00:06:00, 33:33 pkts, 17275:19931 bytes,
rule 48, source-track
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:00:58, expires in 00:05:43, 33:33 pkts, 17275:19931 bytes,
rule 63
all udp 96.251.22.157:55202 (10.128.110.73:9430) -> 198.148.6.55:9430
MULTIPLE:MULTIPLE
age 00:00:58, expires in 00:05:43, 33:33 pkts, 17275:19931 bytes,
rule 48, source-track
etc, etc:
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:02:26, expires in 00:05:52, 37:37 pkts, 18863:23594 bytes,
rule 63
all udp 96.251.22.157:55202 (10.128.110.73:9430) -> 198.148.6.55:9430
MULTIPLE:MULTIPLE
age 00:02:26, expires in 00:05:52, 37:37 pkts, 18863:23594 bytes,
rule 48, source-track
Until finally, there are no more packets for a while:
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:02:36, expires in 00:05:54, 47:46 pkts, 24551:29876 bytes,
rule 63
all udp 96.251.22.157:55202 (10.128.110.73:9430) -> 198.148.6.55:9430
MULTIPLE:MULTIPLE
age 00:02:36, expires in 00:05:54, 47:46 pkts, 24551:29876 bytes,
rule 48, source-track
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:03:31, expires in 00:04:59, 47:46 pkts, 24551:29876 bytes,
rule 63
all udp 96.251.22.157:55202 (10.128.110.73:9430) -> 198.148.6.55:9430
MULTIPLE:MULTIPLE
age 00:03:31, expires in 00:04:59, 47:46 pkts, 24551:29876 bytes,
rule 48, source-track
After this, the next time I look a couple seconds later, the state is
gone? It reproducibly seems to disappear a minute after the last traffic
is seen on the connection. Yet the timeout says 5 minutes are left?
Why would the state be removed when it still had five minutes left
before it expired? I know if it were a TCP state, it might go away
before the timeout expires if the connection is shut down. But this is a
UDP state. What would cause it to go away before the timeout expiration?
Is there something wrong
Re: IPv4 traffic over IPv6 tunnel approach
I have IPv6 point to point connection. Going to transmit IPv4 inside IPv6 tunnel. client has IPv6 ::::2 gateway has IPv6 ::::1 Martin ‐‐‐ Original Message ‐‐‐ On Friday, May 8, 2020 8:55 PM, Brian Brombacher wrote: > From your description, you want to pass IPv4 inside a tunnel that has an > outer protocol of IPv6. Your resulting hostname.gif0 looks like the exact > opposite of your description (IPv6 inside the tunnel with IPv4 outer). > > Clarify what you need please. Provide your existing hostname.if files for the > other interfaces if you need to. > > > On May 8, 2020, at 3:09 PM, Martin martin...@protonmail.com wrote: > > Last thing I have to understand about gif(4) and IPv6 tunneling. > > Should I set gif(4) 'inet6 alias' = the same IPv6 of the local end of IPv6 > > tunnel interface or just set 'inet6 alias' for gif(4) in tunnel's IPv6 > > subnet? > > Martin > > ‐‐‐ Original Message ‐‐‐ > > > > > > On Friday, May 8, 2020 4:41 PM, Tom Smyth tom.sm...@wirelessconnect.eu > > > > wrote: > > > > Hi Martin, > > > > If I understand your question correctly > > > > you need 2 endpoints to the tunnel... > > > > for gif(4) or any gre((4) based tunnel > > > > you need the interface setup on both the client and the server (gateway) > > > > if you have a gateway serving multiple clients... then you need one > > > > interface per client that you intend to connect > > > > Thanks > > > > Tom Smyth > > > > On Fri, 8 May 2020 at 17:38, Martin martin...@protonmail.com wrote: > > > > Thanks for confirmation. > > > > Hope I understand gif(4) functionality right from its configuration. > > > > Can I set /etc/hostname.gif0 from client's side only like below: > > > > /etc/hostname.gif0 > > > > tunnel 10.20.30.40 195.203.212.221 > > > > inet6 alias 2001:05a8::0001::::8542 128 > > > > dest 2001:05a8::0001::::8541 > > > > where > > > > tunnel 10.20.30.40 is client's address, 195.203.212.221 gateway machine > > > > egress IPv4 > > > > inet6 alias is the same IPv6 address of client's IPv6 local interface > > > > or an IPv6 address in the same subnet. > > > > dest IPv6 is a destination IPv6 interface address of gateway machine. > > > > Do I need to setup gif0 on gateway machine to have encapsulation > > > > working? > > > > Martin > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > > > On Friday, May 8, 2020 1:43 PM, Kristjan Komlosi > > > > > kristjan.koml...@gmail.com wrote: > > > > > gif(4) should work fine, as it's designed to do what you described. > > > > > The > > > > > best approach depends on the level of security you want to achieve. > > > > > IPIP > > > > > tunnels aren't encrypted... > > > > > regards, kristjan > > > > > On 5/8/20 3:32 PM, Martin wrote: > > > > > > > > > > > I have IPv6 unidirectional tunnel between two machines. One of them > > > > > > is gateway, another one is a client. > > > > > > The goal is to route IPv4 packets over IPv6 tunnel from client to > > > > > > gateway and NAT IPv4 packet to egress on gateway machine. > > > > > > May I use gif(4) for it or what is the best approach to traverse > > > > > > IPv4 packets over IPv6 tun? > > > > > > Martin > > > > > > -- > > > > > > Kindest regards, > > > > > > Tom Smyth.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
https://www.technologyreview.com/2018/02/21/145300/serious-quantum-computers-are-finally-here-what-are-we-going-to-do-with-them/ https://www.microsoft.com/en-us/research/project/post-quantum-ssh/ https://openquantumsafe.org/ Why not to add post quantum algos to the SSH mainline to make them easily available at once in all up to date distros?
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
According to Damien Miller: >this is pretty much possible now, by enabling the experimental support for the XMSS PQ signature algorithm in the SSH
